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This  report  contains  the  results  of  the  Ground  Operations 
and  Support  Systems  Panel's  deliberations  for  the  Space 
Station  Operations  Task  Force.  This  report  forms  the  basis 
for  some  of  the  recommendations  summarized  in  the  SSOTF 
Summary  Report  dated  December  1987  and  describes  in  greater 
detail  the  Ground  Operations  and  Support  Systems'  major 
function  of  the  Space  Station  Operations  Concept.  To 
obtain  a full  appreciation  of  the  contents  of  this  report 
the  reader  is  advised  to  read  first  the  Summary  Report 
which  describes  the  Ground  Operations  and  Support  Systems 
function  in  context  with  the  other  major  functions  as  part 
of  the  overall  developed  end-to-end  operations  concept.  It 
should  be  noted  that  the  subsections  of  this  report  were 
developed  and  written  by  subgroups  of  the  panel.  As  such, 
the  reader  may  note  differences  in  style  and  continuity 
between  subsections.  Due  to  time  and  resource  limitation, 
no  effort  was  made  to  provide  for  stylized  editing.  Also, 
the  terminology  used  in  this  report  to  describe  the  Ground 
Operations  and  Support  Systems  major  function  may  differ 
slightly  from  that  used  in  the  Summary  Report  in  order  to 
impart  a finer  grain  of  knowledge  to  the  reader.  However, 
the  official  Space  Station  Operations  Concept  Lexicon  is 


contained  in  the  Summary  Report,  and  terms  introduced  in 
this  book,  that  are  not  used  and  defined  in  the  Summary 
Report  or  are  used  in  substitute  of  a term  or  part  of  a 
term  in  the  Summary  Report,  are  listed  on  page  vii  with  an 
explanation  and  further  definition  if  appropriate.  Should 
the  definition  of  a term  in  this  book  be  interpreted  by  the 
reader  to  conflict  with  the  corresponding  definition  in 
the  Summary  Report,  the  definition  in  the  Summary  Report 
will  take  precedence. 

Lastly,  where  recommendations  in  this  report  differ  from 
those  in  the  Summary  Report,  the  Summary  Recommendations 
take,  precedent.  (Recommendations  of  all  panels  were 
reviewed  and  debated  by  the  Task  Force  and  in  some 
instances  were  changed. ) 

Any  questions  or  clarifications  needed  concerning  details 
or  recommendations  contained  in  this  report  should  be 
addressed  to  the  Panel  Chairman,  Hr.  Charles  Mars,  (703) 
487-7254. 


Charles  Mars 


Date 
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GROUND  OPERATIONS 


Executive  Summary 


Introduction 

The  Ground  Operations  Concept  embodied  in  this  report,  provides 
for  ^multi-user  utilization  of  the  Space  Station,  and  i-a  safe., 
eases  user  integration,  and  gives  users  autonomy  and  flexibility. 
It  provides  for  meaningful  multi-national  participation  while 
protecting  U.S.  interests.  The  concept  also  supports  continued 
Space  Operations  Technology  Development  by  maintaining  NASA 
expertise  and  enabling  technology  evolution. 

This  is  accomplished  by  a clear  leadership  and  control  of 
requirements  during  the  Design/Development  Phase  by  the  Design 
Centers/Work  Package  Contractors  with  integration  accomplished 
through  a strong  A*  organization.  Work  Package  Contractors  are 
required  to  develop  plans  and  technical  documentation  so  that  the 
whole  program  could  be  turned  over  to  an  operations  contractor 
with  no  adverse  impact.  This  will  allow  for  an  orderly 
transition  of  leadership  and  control  of  operations  to  the 
Operations  Centers  as  the  mature  operations  phase  is  achieved. 

Pre/Post  Flight  Processing 

Pre/Post  flight  processing  of  payloads  is  an  operational  task 
which  will  be  an  on-going  operations  function  performed  under  the 
NASA  Integrated  Operations  Management  System.  In  order  to 
process  and  integrate  user  experiments /payloads  in  an  efficient, 
user  friendly  manner,  A Payload  Accommodations  Manager  (PAM) 
function  is  required  to  manage  the  experiments /payloads  both  for 
ground  and  flight  processing.  For  the  ground  processing  flow, 
the  PAM  has  to  work  with  the  users  during  the  initial  generation 
of  the  users  requirements,  through  the  ground  hardware  flow,  to 
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the  return  of  the  product  from  the  Space  Station.  The  flight 
counterpart  of  the  PAM  would  work  the  experiment/payload 
on-orbit,  from  a designated  support  center. 

When  a user  experiment /pay load,  either  International  or  United 
States,  is  designated  to  fly  on  Space  Station,  a launch  vehicle 
(U.S.  ELV/International  ELV  or  Space  Shuttle)  will  be  assigned. 

If  the  experiment  requires  a rack  buildup,  the  buildup  will  take 
place  at:  1)  Science  and  Technology  Centers),  2)  International 
rack  build-up  areas,  3)  Kennedy  Space  Center.  This  user  friendly 
approach  allows  maximum  flexibility  for  experiment  build  up  in  a 
parallel  schedule  mode.  The  integrated  racks  will  undergo  a rack 
interface  test  with  a SS  interface  simulation  to  assure  an 
optimum  safety  and,  SS  interface  certification.  Also  multiple 
launch  vehicle  capabilities  and  parallel  build-up  allow  for 
flexibility  in  up-load  manifesting.  A representative  of  the 
Payload  Accommodations  Manager  will  manage  the  flow  support 
through  the  entire  process.  The  PAM  concept  allows  a consistent 
NASA  involvement  throughout  the  processing  of 
payloads/experiments . 

The  logistic  module  will  be  utilized  to  both  up-load  and 
down-load  payload  to  the  Space  Station.  A early/ late  access  is 
required  for  the  logistics  module  for  landing/ launch  time  frames. 
Life  Science  Experiments  as  well  as  time/temperature/environment 
critical  experiments  will  require  expeditious  handling  both  at 
the  launch  and  landing  sites.  The  early/late  access  capability 
needs  to  be  incorporated  in  the  U.S.  or  International  logistics 
modules. 

Integrated  Logistics  Systems 

The  Integrated  Logistics  System  report  addresses  the  following 
major  functions: 

Maintenance  on  Orbit  Packing  and  Handling 
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Maintenance  on  Ground 
Material  Management 
Transportation 
Training 


Facilities 

Technical  Documentation 
User  Support 
Logistics  Management 


Maintenance  and  resupply/ return  are  the  two  prime  tasks  for  S.S. 
Logistics  in  the  operational  phase.  The  management  structure 
necessary  to  ensure  the  effective  and  efficient  management  of 
Space  Station  maintenance  and  resupply/ return  must  cope  with  the 
diversity  of  integration  and  management  interfaces.  It  must  be 
capable  of  integrating  strategic,  tactical  and  execution  level 
planning.  It  roust  identify  accountability  for  Space  Station 
performance  and  it  must  manage  the  systemic  processes  and  issues 
which  cross  institutional  and  management  level  boundaries. 

In  the  recommended  concept,  the  level  A*  organization  would 
provide  the  strategic  and  tactical  integration  across 
requirements  and  integrate  the  planning  requirements  across 
ground  operations,  logistics  and  on-orbit  operations.  The 
Logistics  Operations  Center,  located  at  the  Ground  Operations 
Center,  would  provide  the  day  to  day  management  of  Space  Station 
logistics  support.  It  would  provide  technical  logistics  support 
to  the  TOCB  process  and  would  manage  resupply /return,  and 
maintenance  both  on-orbit  and  on  the  ground. 

The  establishment  of  the  dedicated  headquarters  logistics 
function  and  the  Logistics  Operations  Center  will  provide  the 
continuity  of  logistics  planning  and  execution  necessary  to 
support  the  program.  The  remaining  Integrated  Logistics 
Functions  are  addressed  in  detail  in  the  Logistics  section  of  the 
report.  Significant  findings  of  the  Integrated  Logistics  Panel 
are  elaborated  in  white  papers.  Some  of  the  findings  are  as 
follows: 


1.  Current  planning  for  logistics  facilities  equipment  and 
manpower  is  based  on  an  estimated  60,000  line  items  of 
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inventory,  while  the  Task  Force  estimates  300,000  line 
items . 

2.  Lessons  Learned  from  LPS  Development 

o Specifications  and  purchase  documentation  up  front 
(including  testability  and  diagnostics)  testability 
o Plan  for  assumption  of  maintenance 
o Plan  for  ATE  and  AI 

o Provision  lifetime  spares  during  manufacturing 

3.  Review  of  Air  Force  Recon  Program 

o Use  standard  state-of-the-art  hardware,  software  and 
firmware 

o Uniform  R&M  design  requirements 

o Make  manufacturer  responsibiliyt  for  reliability  of  BITE 
o Business  strategy  needs  to  support  logistics 
strategy 

o Maintenance  data  gathering  should  be  automated,  user 
friendly  and  useful  to  inputter 
o Operations  contractor  should  be  part  of  design  process 
o Buy  complete  technical  data  in  acquisition  process 

Logistics  operations  (up-load,  down-load,  SS  system 
refurbishment)  will  be  one  of  the  largest  operational  tasks  and 
cost  drivers  of  the  mature  Space  Station  program. 


Sustaining  Engineering 

Sustaining  Engineering  is  an  assigned  role  of  the  Space  Station 
Program  and  is  an  on-going  operational  function  performed  under 
the  integrated  operations  management  system  of  the  Space  Station 
program.  Sustaining  Engineering  is  defined  as  maintaining  a 
design  that  fulfills  original  design  intent  and  is  compatible 
with  intended  operational  use.  Problems  are  resolved  to  keep  the 
hardware /software  systems  in  an  operational  status.  Operational 
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performance  is  enhanced  through  product  improvement/redesign  for 
more  cost  effective  and  efficient  operations.  Approved  changes 
in  design  and  requirements  are  incorporated  as  a part  of  system 
evolution.  Sustaining  Engineering  excludes  major  upgrading  of 
existing  systems  or  the  acquisition  of  new  systems  if  more  than 
incidental  research  and  development  is  required,  but  supports  new 
development  to  gain  the  expertise  necessary  to  operationally 
sustain  new  systems  after  turnover  from  the  Development  Centers. 

The  Space  Station  consists  of  flight  elements  designed  and 
developed  by  NASA,  Internationals,  and  Users.  Each  of  these 
elements  will  be  responsible  for  the  Sustaining  Engineering  of 
the  hardware  and  software  provided  for  that  element  of  Space 
Station  Operations.  NASA  has  the  overall  responsibility  of 
performing  the  analysis  to  ensure  the  compatibility  and  safety  of 
user /International  design  performance. 

The  Space  Station  Sustaining  Engineering  Organizations  at  the 
Operations  Centers  will  accbmplish  the  major  functions  of 
Sustaining  Engineering  under  the  centralized  management  and 
control  system  at  NASA  Headquarters.  This  provides  a singular 
management  interface  to  the  Internationals  and  users,  as  well  as 
a single  approach  to  maintenance  of  the  Space  Station  Engineering 
Data  Base  (SSEDB)  throughout  mature  operations.  A standard 
system  will  be  provided  for  processing  engineering  changes  and 
updating  affected  Space  Station  Documentation.  The  Operations 
Centers  provide  the  technical  support  and  analysis  for  the 
tactical  planning. 

NASA  lead  Centers  have  expertise  in  various  disciplines  which  are 
reflected  in  the  Space  Station  Work  Package  Concepts  required  to 
design  and  develop  the  Space  Station.  The  Space  Station  Program 
has  been  divided  for  design  purposes  into  three  phases,  1)  Design 
and  Development  (D&D), 

2)  Transition  and  3)  Mature  Operations.  For  the  D&D  Phase  the 
work  package  centers  will  design  the  Space  Station 
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hardware /software.  In  order  to  sustain  an  operational  program 
for  a twenty  to  thirty  year  period,  the  NASA  Development  Centers 
should  be  released  from  the  development  engineering  role  on  the 
Space  Station  at  the  earliest  opportunity  as  their  resources  are 
required  for  other  long  range  national  programs.  A concerted 
plan  between  NASA  Space  Station  Operations  and  the  NASA 
Development  Organizations  must  define  the  transition  phase 
required  to  obtain  the  mature  operations  phase. 

The  recommended  transition  concept  is  to  have  the  Launch  Site 
Sustaining  Engineering  representative  involved  with  the  early 
development  and  design  of  the  Space  Station  hardware/ software. 
Approximately  three  years  prior  to  Initital  Operations  Capability 
(IOC),  the  Launch  Site  Sustaining  Engineering  Operation  should  be 
in-place;  thereby,  allowing  an  orderly  turnover  of  engineering 
from  the  Development  Centers  on  a system  by  system  basis.  The 
turnover  would  be  done  incrementally  depending  on  system  design 
maturity  and  complexity. 

All  Development  Test  beds  and  equipment  required  for  future 
National  Research  would  remain  at  the  Development  Centers.  Space 
Station  peculiar  support  equipment  would  be  centralized  at  the 
Launch  Center  for  mature  operations.  The  Launch  Center 
Sustaining  Engineering  would  retain  and  update  the  Space  Station 
Engineering  Data  Base  and  have  the  capability  to  accomplish  the 
Sustaining  Engineering  for  Space  Station  during  the  mature 
operations  phase. 


Transportation  Services 

The  Space  Station  in  the  operational  era  will  require  heavy 
support  of  Space  Transportation  Systems.  Transportation  Systems 
include  those  used  for  launch  from  earth,  on-orbit  mobility,  crew 
rescue  and  return  to  earth. 
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During  the  Space  Station  operational  era  a mixed  fleet  of  launch 
vehicles  is  required.  The  payload  capacity  of  the  Space  Shuttle 
is  only  thirty  to  forty  thousand  pounds  (depending  on  which 
orbiter  is  used)  which  is  insufficient  for  many  Space  Station 
applications.  The  down-load  of  the  shuttle  orbiters  is  even  less 
than  the  up- load.  With  the  expected  orbiter  fleet  of  four 
vehicles,  the  expected  flight  rate  will  only  be  about  14-16 
flights  per  year.  Dse  of  other  vehicles,  such  as  Shuttle  Derived 
Vehicles  (SDVs),  expendables  (International  and  D.S.),  that  do 
not  require  manned  flight,  would  greatly  relieve  the  scheduling 
load  on  the  shuttle.  Dse  of  ELV’s  and  SDV's  is  mandatory  for  a 
viable  Space  Station  Program.  The  shuttle  would  still  be  used 
for  crew  rotation. 

An  interesting  facet  of  the  logistical  use  of  International 
Expendable  Launch  Vehicles  for  up-load  and  down-load  payload  to 
the  Space  Station  is  that  a barter  system  could  be  arranged  to 
allow  a trade  of  services  between  the  D.  S.  and  International 
Partners  in  a mutually  complimentary  manner. 

The  ability  to  rapidly  rescue  the  entire  crew  from  a disabled 
Space  Station  is  a major  requirement.  The  safe  haven  capability 
that  is  provided  on  the  Space  Station  cannot  adequately  address 
failure  modes.  A means  for  rescue  must  be  provided.  Rapid 
return  to  earth  of  a seriously  ill  crewman  is  also  desired  so 
that  proper  medical  attention  can  be  obtained.  Options  include: 
1)  an  orbiter  on  standby,  2)  orbiter  on  orbit,  3)  a crew 
emergency  return  vehicle,  and  4)  international  shuttle/expendable 
rescue  vehicles.  Of  the  options  considered,  an  automated  Crew 
Emergency  Return  Vehicle  (CERV)  attached  to  the  Space  Station  is 
the  most  viable.  The  CERV  could  serve  either  as  an  rescue 
vehicle  or  a safe  haven  in  an  emergency  situation  without 
dependency  on  an  earth  based  capability. 

Transportation  Services  will  be  one  of  the  largest  cost  drivers 
of  the  Space  Station  Program  during  the  mature  operations  phase. 
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Information  Systems  and  Communication 


The  complexity  of  the  operation  of  the  Space  Station,  its 
physical  remoteness,  the  continuing  change  of  mission  as  new 
experiments  are  taken  up  to  the  Station,  and  the  importance  of 
safety  and  reliability  all  place  heavy  burdens  on  the 
requirements  for,  and  importance  of,  ground  information  and 
communication  systems.  User  needs  for  access  to  their 
experiments,  either  in  ground  test  facilities  or  in  the  Station 
and  the  associated  data,  will  also  rely  on  these  systems  to  some 
extent.  The  proper  implementation  and  operation  of  these  systems 
will  contribute  significantly  to  the  overall  effectiveness  of  the 
Space  Station  operations. 

The  Information  and  Communications  Systems  during  the  operational 
phase  of  the  SSP  must  be  highly  intergrated  with  the  many 
computer  systems  networked  for  the  sharing  of  data  on  a large 
scale.  There  must  be  interfaces  among  all  organizational  aspects 
of  the  program,  including  flight  operations,  ground  processing, 
logistics,  and  sustaining  engineering.  Planning  must  be  initiated 
now  to  eliminate  pockets  of  "uniqueness " whether  generated  by 
desire  to  stay  with  old  systems  or  because  of  political 
boundaries.  A high  level  of  control  and  management  commitment 
must  be  in  place  to  manage  database  and  network  architecture  and 
design. 

Evolution  must  be  planned  for  in  all  operational  information 
systems.  Budget  projections  must  include  capital  costs. 
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2.0  PRE/POST  FLIGHT  OPERATIONS 


2.1  OVERVIEW 

The  Pre/Post  Flight  Operations  subpanel  of  the  Ground  Opera- 
tions and  Support  Systems  Panel  was  chartered  with  the  task  to 
develop  the  concept  for  conducting  pre/post  flight  operations 
for  Space  Station  incremental  missions.  These  operations 
include:  1)  analyze  and  verify  the  mission  complement  to  the 

Space  Station  and  National  Space  Transportation  System  (NSTS) 
carrier;  2)  perform  physical  integration  and  verification  of 
the  mission  hardware;  3)  provide  for  late/early  stowage  of 
mission  items;  4)  perform  recertification  of  flight  hardware; 
and  5)  define  facilities  to  support  mission  processing.  The 
concept  addresses  mature  operations,  that  is,  operations  in  the 
year  2010,  however,  specific  recommendations  are  presented  for 
implementation  during  the  C/D  phase  that  will  enhance  achieving 
the  mature  operations  concept. 

The  concept  developed  will  be  focused  on  the  three  main 
elements  of  pre/post  flight  operations:  analytical  integration 

of  payloads,  physical  integration  of  payloads,  and  support 
functions  for  payloads  processing. 

The  concept  for  the  accomplishment  of  the  payloads  analytical 
integration  entails  the  optimum  utilization  of  four  major 
participants  which  are:  the  users.  Science  and  Technology 

Centers  (S&T),  Payload  Integration  Organization  (PIO),  and  the 
NSTS.  The  users,  if  a member  of  a discipline  of  a S&T  Center, 
will  interface  through  the  S&T  Center  for  the  analytical 
integration  activities.  If  the  user  is  not  represented  by  an 
S&T  Center,  he  will  work  directly  with  the  PIO.  The  S&T  Center 
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not  only  will  be  the  interface  for  their  users,  but  will 
provide  coordination  support,  and  interface  to  the  PIO  for 
payloads  in  their  particular  discipline.  The  PIO  is  the 
responsible  organization  for  performance  of  the  total  mission 
analytical  integration  and  it  will  provide  the  interface  and 
support  to  the  NSTS.  The  NSTS  is  the  responsible  organization 
for  the  NSTS  flight  for  the  Space  Station  mission. 

The  concept  for  the  physical  integration  activities  is  one  of 
decentralization/centralization.  The  Space  Station  payload 
support  elements;  i.e.,  racks  and  Payload  Interface  Adapters 
(PIA),  will  be  provided  to  the  S&T  Centers  or  to  other  Space 
Station  approved  organizations;  i.e.,  international  or  commer- 
cial , to  perform  physical  integration  and  interface  testing  of 
the  payload  to  the  support  elements.  The  integrated  racks  or 
PIAs  would  then  be  delivered  to  the  launch  site  where  they  are 
integrated  with  the  Space  Station  interface  simulation  equip- 
ment for  payload  to  Space  Station  interface  functional 
compatibility  verification  and  then  final  launch  preparation. 
Space  Station  platforms  would  be  integrated  and  functionally 
verified  at  their  final  assembly  and  integration  site  and  then 
provided  to  the  launch  site  for  launch  preparation.  Provisions 
would  be  provided  by  the  Space  Station  Program  to  accommodate 
late  stowage  (on  the  pad)  and  early  removal  (at  landing 
strips),  in/from  the  Space  Station  logistic  carriers  of  payload 
items . 

In  the  area  of  support  to  payload  processing,  the  concept 
addresses  recertification  of  the  flight  hardware  and  payload 
unique  support  facilities  for  payload  processing.  The  Space 
Station  Sustaining  Engineering  Organization  would  manage  and 
control  the  requirements  for  recertification  with  implementa- 
tion of  the  requirements  by  the  launch  site  organization. 
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Unique  payload  support  facilities  have  been  identified.  The 
programmatic  provisioning;  i.e.,  commercial  rental,  NASA 
facilities  with  user  rental  fee,  etc.,  is  dependent  on 
individual  requirements . 

The  functioning  of  several  organizations  performing  defined 
roles  is  required  for  implementation  of  the  operations  concept. 
These  organizations  and  their  major  roles  are  as  follows: 

Users  - Develop  and  provide  payload  hardware  and  participate  in 
and  support  the  integration  process. 

Science  and  Technology  (S&T)  Centers  - Integrate  discipline 
users  requirements  and  provide  surrogate  role  and  support  for 
them  during  the  integration  process. 

Payload  Integration  Organization  (PIO)  - Manages  and  performs 
analytical  integration  activities 

Launch  Site  - Manages  and  performs  launch  site  processing. 
Performs  build  up  of  payloads  not  assigned  to  S&T  Centers  or 
others;  i.e.  commercial,  DoD,  etc. 

National  Space  Transportation  System  (NSTS)  - Manages  and 
provides  flight  services  for  Space  Station  missions. 

Recommendations  from  the  Pre/Post  Flight  Operations  Subpanel 
for  consideration  by  the  Space  Station  Program  for 
implementation  during  Phase  C/D  are  as  follows: 

o Procure  the  required  complement  of  Space  Station 

hardware;  i.e.,  rack.  Payload  Interface  Adapters  (PIA), 
Simulators  transportation  6SE , etc.,  required  to 
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implement  the  concept  of  decentralization  of  payload 
physical  integration. 

o Establish  the  organizational  structure  for  the  Payload 
Integration  Organization  and  implement  the  PIO  to 
perform  the  payload  integration  functions. 

o Provide  capability  in  the  logistics  elements  for 
late/early  payload  accessibility. 

2.2  DETAILS  OF  CONCEPT 


2.2.1  Roles /Responsibilities 

The  implementation  of  the  operations  concept  for 
pre/post-flight  operations  during  the  operational  phase  of  the 
Space  Station  Program  will  entail  the  functioning  of  several 
organizations.  These  organizations  will  be  interactive  and 
they  must  understand  the  roles,  functions,  and  responsibilities 
of  each  other  and  operate  within  the  roles  framework  to  achieve 
optimum  efficiency.  This  section  will  endeavor  to  delineate 
the  roles,  functions/responsibilities  of  each  of  the 
organizations.  The  organizations  or  major  functional  entities 
in  the  concept  are:  the  users.  Science  and  Technology  Centers 
(S&T),  Payload  Integration  Organization  (PIO),  National  Space 
Transportation  System  (NSTS),  and  the  launch  site  organization. 
The  diagram  of  the  concepts'  organizational  structure  is 
presented  in  Figure  2-1. 

Roles 


The  prime  roles  of  each  of  the  functional  entities  are  defined 
in  the  following  paragraphs. 

Osers  - The  major  role  of  the  users  will  be  to  conceive, 
design,  and  develop  experiments  to  be  performed  on  Space 
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Station.  This  may  entail  the  development  of  payload  hardware 
to  be  sent  to  the  Space  Station  or  use  of  payload  hardware 
already  onboard  Space  Station.  The  user,  once  selected  for 
Space  Station  operations,  will  provide  his  requirements  for 
utilization  of  Space  Station  Program  resources,  support  the 
activities  associated  with  integrating  his  requirements  into 
Space  Station  operations,  support  and/or  conduct  on-orbit 
experiment  operations,  and  then,  as  required,  report  on  his 
experiments  status. 

Science  and  Technology  (S&T)  - The  S&T  Centers  serve  a vital 
role  in  integrating  user  experiments  into  the  Space  Station 
program.  Beginning  with  the  concept  of  Space  Station,  the  S&T 
expertise  has  been  applied  in  defining  facilities  and  require- 
ments for  the  elements  of  Space  Station  including  the 
laboratory  pressurized  module,  the  habitability  facility, 
platforms,  and  attached  payloads.  The  S&T  Centers  maintain 
active  R&D  programs  encompassing  activities  representative  of 
proposed  0-g  experiments.  Their  natural  role  is  to  serve  as 
representatives  of  the  science  proposer  in  the  various 
disciplines,  i.e.,  JSC  for  human  associated  life  sciences 
activities,  ARC  for  nonhuman  (animals,  plants, 
microbiologicals,  exobiology)  associated  life  sciences,  MSFC 
for  materials  processing,  GSFC  for  astrophysics  and  earth 
sciences,  and  LeRC  for  microgravity  technology. 

Payload  Integration  Office  (PIO)  - The  PIO  will  perform  the 
primary  role  of  integrating  users  requirements  into  the  ongoing 
Space  Station  physical  plant  and  operations.  The  PIO  role  will 
be  to  perform  the  function  required  to  integrate,  verify,  and 
certify  for  the  Space  Station  and  to  the  NSTS  each  Space 
Station  Incremental  Mission. 
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National  Space  Transportation  System  (NSTS)  - The  role  of  the 
NSTS  organization  in  the  Space  Station  era  will  be  basically  as 
it  is  today.  The  NSTS  will  have  the  primary  role  of 
integrating  Space  Station  payloads  to  the  launch  vehicle, 
launching  the  launch  vehicle,  and  conducting  in-flight 
operation,  to  deliver  payloads  to  the  Space  Station.  The  NSTS 
will  perform  a similar  role  for  returning  payloads  from  the 
Space  Station. 

Launch  Site  - The  launch  site  role  in  the  processing  of  Space 
Station  payloads  will  be  very  similar  to  what  is  being  done  now 
in  the  Spacelab  Program.  The  launch  site  will  perform  physical 
integration  of  experiments  not  assigned  to  S&T  Centers  or 
others  (DoD,  commercial).  The  launch  site  prime  role  for  Space 
Station  payloads  will  be  to  physically  integrate  the 
individually  provided  payload  elements  into  a Space  Station 
Incremental  Mission  payload  complement  and  perform  the 
integrated'  interface  compatibility  verification  of  this  payload 
complement  to  a Space  Station  simulator.  It  will  subsequently 
integrate/verify  Space  Station  carriers  and  perform  prelaunch 
activities.  A corresponding  role  will  be  performed  as  required 
for  the  return  flight  from  the  Space  Station. 

Functions/Responsibilities 

Dsers  - The  functions  that  are  the  prime  responsibility  of  the 
users  and/or  his  representative  and  to  be  performed  to 
implement  the  pre/post  flight  concept  are  listed  below. 

o Develop  experiment  hardware /software 
o Define/document  Space  Station  resource  requirements 
o Define/document  Space  Station  interface  requirements 
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o Define/document  pre/post  flight  ground  processing 
requirements 

o Review  PIO  prepared  documentation 
o Support  payload  integration  reviews 

o Perform/document  experiment  verification  analyses  and 
test 

o Perform/document  safety  analyses  and  provide  safety 
compliance 

o Interface  to  S&T  Center  or  PIO  as  appropriate 

o Perform/ support  experiment  hardware  integration  and 
test 

o Support  pre/post  launch  activities 

o Conduct /support  on-orbit  Space  Station  operations 

o Receive,  process,  analyze  experiment  returned  hardware, 
products , data , etc . 

o Reports  on  status  of  experiment  operations 

Science  and  Technology  Centers  (S&T)  - In  the  event  the  user  is 
represented  by  an  S&T  Center,  the  S&T  Center,  in  actuality, 
performs  the  functions  described  under  the  preceding  section. 
The  S&T  Center  is  responsible  for  the  following: 

o Design  Engineering 

- Payload  analytical  integration 

- Experiment  hardware  design  and  fabrication 

- GSE  design  and  fabrication 
o Operations 

- Experiment  requirements  preparation  with  user  and 
science  representative 

- Hardware  physical  integration  and  test 
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- Hardware  verification  and  safety 

- Assemble  all  PlO/payload  required  documentation 

- Phased  and  flight  training 
Flight  support  with  analyses 
Formal  interface  to  PIO 

o Data  Systems 

- Define,  design,  implement  experiment  flight  and 
ground  software 

o Science 

- Assure  user  science  objectives  are  met  in  experiment 
design 

- Provide  biocompatibility  support  testing  of  flight 
elements 

- Support  in-flight  and  post-flight  experiment  analysis 
o Sustaining  Engineering 

- Maintenance  of  on-board  experiment  facilities 

Payload  Integration  Organization  (PIO)  - The 
functions /responsibilities  to  be  performed  by  the  Payload 
Integration  Organization  (PIO)  in  the  implementation  of  the 
pre/post  flight  operational  concept  are  listed  below. 

o Develop  user  friendly  documentation  covering  Space 
Station  operational  and  functional  capabilities 

o Provide  single  point  contact  for  payloads  for  S&T 
and/or  users 

o Provide  single  point  contact  for  Space  Station  Mission 
to  the  NSTS 

o Obtain/coordinate  Space  Station  resource  requirements , 
and  ground  processing  requirements  for  payload  elements 
from  S&T  Centers  and/or  users 
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o Perform  analytical  integration  of  integrated  mission  to 
confirm  compatibility  of  payload  mission  requirements, 
to  Space  Station,  Space  Station  logistic  carriers,  and 
STS  launch  vehicles 

o Obtain/assess  payload  elements  verification  data  from 
S&T  Centers  and/or  users 

o Perform  mission  integrated  payload  verification 

o Obtain/assess  payload  elements  safety  compliance  from 
S&T  Center  and/or  users 

o Perform  mission  integrated  safety  analysis  and  provide 
safety  certification 

o Develop  payload  mission  integrated  documentation 

o Develop  and  provide  to  NSTS  mission  payload  data  for 
developing  NSTS  Payload  Integration  Plan  (PIP) 
documenta t ion 

o Develop  and  provide  to  launch  site  mission  payload 
ground  processing  requirements 

o Obtain  and  integrate  Logistics  requirements  into 
mission  payload 

o Verify /certify  flight  readiness  of  integrated  mission 
Space  Station  payload 

National  Space  Transportation  System  (NSTS)  - The 
function/responsibilities  of  the  NSTS  organization  in  support 
of  Space  Station  missions  will  be  essentially  as  for  standard 
NSTS  missions.  Some  other  specific  functions  that  may  require 
significant  interaction  to  the  PIO  are  listed  below. 

o Develop  NSTS  PIP  documentation  in  conjunction  with  PIO 

o Provide  crew  training  for  payload  unique  operations 

o Provide  access  and/or  perform  late  loading  of  payload 
items 

o Provide  access  and/or  perform  early  removal  of  payload 
items  after  return  from  Space  Station 


2-10 


o Provide  standard  launch/ flight  operations 


Launch  Site  - The  functions/responsibilities  to  be  performed  by 
the  launch  site  in  the  implementation  of  the  pre/post  flights 
operations  concept  are  listed  below. 

o Conduct  ground  operations  review  to  assess/work  payload 
problems 

o Develop  ground  integration/test  procedures  from  payload 
element  inputs 

o Perform  payload  physical  integration/deintegration, 
where  required 

o Receive  payload  integrated  (racks,  PIA)  elements 

o Perform  integrated  payload  mission  testing  to  Space 
Station  simulator  for  interface  compatibility  and 
safety 

o Perform  integration/deintegration  of  Space  Station 
logistics  carriers 

o Perform  Space  Station  logistics  carrier/payload 
interface  testing 

o Integrate  and  verify  Space  Station  logistics  carrier  to 
launch  vehicle 

2.2.2  Space  Station  Program 


Introduction 


Pre/post  flight  operation  functions  begin  subsequent  to  the 
selection  and  manifesting  of  a user  to  a Space  Station  mission 
segment  and  the  supporting  NSTS  flights  and  carries  through  to 
the  return  of  products  and/or  hardware  from  orbit.  The  period 
of  user  involvement,  in  most  cases,  will  be  of  a multi-year 
time  span.  The  degree  of  user  involvement  will  be  a function 
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of  the  payload  hardware  and  functional  interfaces  to  the  Space 
Station,  the  NSTS  payload  carrier  and  to  the  NSTS  launch 
vehicle.  Pre/post  flight  operations  include  considering  the 
logistics  resupply  (Orbit  Replaceable  Units,  supplies,  etc.)  as 
a user  payload  to  be  manifested  along  with  experiment  payloads 
in  the  logistics  carriers. 

The  areas  which  were  identified  as  significant  to 
pre/post-flight  processing  and  for  which  various  options  were 
evaluated  to  arrive  at  a pre/post  flight  concept  are  as 
follows: 

o Analytical  integration  of  payloads  with  the  Space 

Station  program  (and  the  NSTS)  including: 

- Involvement /interface  of  the  Space  Station  with  the 
NSTS 

- Payload  interface  analyses  with  the  Space  Station 
and  NSTS  Programs 

- Documentation  type  and  mode  to  support  user 
analyses. 

o Physical  integration/deintegration  of  payloads  with  the 

Space  Station  program  including: 

- Payload  and  logistics  carrier  hardware/ software 
buildup 

- Level /degree  of  verification  testing 

- Distribution  of  payload  early  removal  items 

- Late  access  to/early  removal  of  payload  items. 

o Support  of  pre/post  flight  operations  including: 

Recertification  of  flight  hardware 

- User  support  facilities. 


2-12 


Various  assumptions  and  guidelines  were  established  to  aid  and 
focus  the  option  evaluation  process  to  significant  areas  of 
consideration.  Guidelines  and  definitions  are  identified  in 
Appendix  A. 

Background.  During  the  Phase  B activities  of  the  Space  Station 
Program,  consideration  was  given  to  areas  of  pre/post  launch 
operations,  ground  processing  facilities  and  equipment,  and 
Space  Station  program  integration  with  the  NSTS.  The  focus  of 
these  considerations  was  mainly  on  the  assembly  and  checkout 
phases  leading  to  Initial  Operational  Capacity  of  the  Space 
Station.  Program  level  requirements  and  planning  documents 
were  baselined  for  these  areas  as  follows: 

JSC  30000,  Program  Definition  and  Requirements  Document  (PDRD), 
Section  4,  Part  1,  Prelaunch/postlanding  operations 
requirements . 

JSC-30202  11/18/86,  Prelaunch/Postlanding  Operations  Plan. 

JSC-21053  Space  Transportation  System/Space  Station  Pro- 
gram/Payload Integration  Plan. 

KSC-STA-60.01  12/17/86,  Space  Station  Processing  Facility, 

( SSPF ) Facility  and  Equipment  Requirements  Document  (FERD). 

JSC  30000,  PDRD,  Section  3,  Part  4.1:  Master  Verification 

Requirements 

These  documents  provided  background  information  for  considera- 
tion of  the  various  concepts  associated  with  pre/post  flight 
operations  for  the  mature  operational  phase  of  the  Space 
Station  Program. 
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Numerous  briefings  were  held  which  provided  useful  data  related 
to  the  past  experiences  of  the  STS  program  (payload  integra- 
tion), the  Spacelab  Program  (multiple  users  integrated  into  the 
Spacelab),  various  users  and  user  community  representatives, 
and  USAF  payload  programs.  See  Appendix  B for  a listing  of 
briefings /documents.  Useful  information  was  obtained  from 
these  sources  in  the  areas  of  level  of  verification,  analytical 
and  physical  integration  of  payloads,  and  documentation. 

The  method  used  to  evaluate  the  various  options  identified  for 
the  analytical  and  physical  integration  and  support  of  payload 
processing  was  a subjective  rating/ranking  of  the  attributes  of 
each  option  against  the  following  criteria: 

o Feasibility 
o Flexibility 
o User  friendliness 

o Transition  from  development  phase  to  mature  operations 
o Effectiveness  of  management,  cost  and  performance 
o Safety 

o Ease  of  proprietary  operations. 

For  a definition  of  these  criteria  as  used  in  pre/post  flight 
operations  considerations  see  Appendix  C.  The  rating/ranking 
of  the  options  varied  among  the  evaluators  but  generally  led  to 
a predominant  choice  of  option.  The  ratings  for  each  option 
were  thoroughly  discussed,  particularly  for  those  options  with 
widely  differing  ratings,  to  identify  the  key  qualities  of  each 
option.  An  attempt  was  made  in  each  area  to  arrive  at  a 
consensus  choice,  with  all  concerns  discussed  and  evaluated. 

The  options  selected  for  the  pre/post  flight  functions  will  be 
presented  within  the  framework  of  the  flow  of  hardware  and 
documentation  for  processing  of  payloads  to  orbit  and  for 
payloads  returned  from  orbit.  The  key  attributes  of  the 
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selected  option  will  be  identified,  particularly  against  the 
major  criteria  of  user  friendliness,  management  effectiveness, 
and  cost  effectiveness. 

Pre /Post-Flight  Operations  Concept.  The  conceptual  flow  of 
hardware  and  documentation  from  the  user  community  to  the  Space 
Station  program  under  the  pre/post  flight  operations  concept 
for  payloads  selected  to  be  manifested  is  shown  in  Figure  2-2. 
The  concept  description  that  follows  covers  the  previously 
identified  elements:  analytical  integration,  physical 

integration,  and  support  functions  to  processing. 

The  analytical  integration  concept  begins  with  a description  of 
user  interfaces  with  the  Space  Station  program,  including  the 
supporting  documentation  for  user  analyses  and  the  involvement 
of  the  NSTS  program  with  the  Space  Station/user. 

The  physical  integration  concept  starts  with  a description  of 
experiment  integration  with  Space  Station  flight  elements 
including  a discussion  of  the  level  of  and  approach  to  verifi- 
cation. The  process  continues  with  a description  of  the 
integration  of  payload  hardware  into  the  logistics  carriers, 
including  a discussion  of  the  approach  for  late  access/early 
removal  of  payloads,  experiments,  products  etc.  The  process  is 
concluded  with  a description  of  the  approach  to  distribution  of 
early  removal  items  to  the  users. 

Two  areas  of  support  to  the  pre/post  flight  operations 
described  are:  recertification  of  flight  payload  processing 

hardware  and  user  support  facilities. 
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PRELAUNCH/POSTFLIGHT  FLOW 
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Analytical  Integration 


Payload  Analysis  - The  payload  analytical  integration  process 
for  the  user  begins  once  he  has  been  manifested  for  a Space 
Station  incremental  mission  and  the  supporting  NSTS  flights  for 
the  mission  interval . The  scope  of  the  analytical  integration 
process  encompasses  the  following:  determination  of  the  users 

requirements  for  interfaces  to  Space  Station  elements.  Space 
Station  logistics  carriers  and  NSTS;  development  of  require- 
ments for  prelaunch/post-landing  processing,  logistics,  soft- 
ware, safety,  and  verification  compliance;  performance  and 
documentation  of  the  analyses/ test  to  verify  the  compatibility 
to  payload  element  interfaces,  functional  operations,  and 
safety  to  the  Space  Station,  Space  Station  logistics  carrier 
and  NSTS,  as  appropriate;  and  performance  and  documentation  of 
the  integrated  analyses  of  the  total  payload  complement  to  the 
Station  or  NSTS  carriers.  In  summary,  the  analytical 
integration  process  provides  the  requirements/planning  for  the 
physical  integration  activities,  and  accomplishes  the  planning, 
analyses,  reviews,  verifications,  compliances,  certification, 
etc.,  that  are  required  to  integrate  the  new  payload  elements 
into  the  ongoing  Space  Station  operations  and  verify  that  they 
are  ready  for  flight  and  on-orbit  operations. 

The  accomplishment  of  analytical  integration  activities  re- 
quires detailed  interfacing  with  the  users.  Space  Station 
elements,  and  the  NSTS  organization.  The  user  involvement  can 
be  quite  extensive  and  extend  over  a protracted  period  of  time, 
depending  on  his  payload  element.  For  the  highly  autonomous 
payload  with  few  or  very  benign  interfaces,  the  process  will  be 
mainly  concerned  with  the  safety  compliance  of  the  hardware. 
However,  for  the  complex,  highly  interactive  payloads,  the 
process  will  be  very  detailed  and  demand  high  involvement  by 
the  user.  The  concept  that  has  evolved  recognizes  this  and 
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provides  the  flexibility  to  simplify  the  user  involvement. 


CONCEPT  - The  concept  of  the  functional  structure  required 
to  accomplish  the  payload  analytical  integration  functions 
is  presented  in  diagram  form  in  Figure  2-3  In  the  concept, 
both  Science  and  Technology  (S&T)  Centers  and  the  Payload 
Integration  Organization  (PIO)  are  major  participants.  As 
can  be  seen  from  the  Figure,  the  concept  would  provide  a 
separation  between  the  Space  Station  and  NSTS  Programs. 

The  PIO  would  be  an  integral  part  of  the  Space  Station 
organization.  The  S&T  Center  for  the  particular  science 
or  technology  that  the  user  is  engaged  in  would  provide 
the  primary  interface  for  that  user.  The  S&T  Center  would 
act  as  a surrogate  for  the  user  and  support  him  in 
defining  his  requirements,  understanding  Space  Station  and 
NSTS  requirements,  performing  and  documenting  the  required 
analyses/test  to  verify/certify  his  hardware  interface 
compatibility,  and  verification  of  safety  compliance.  The 
PIO,  which  is  a functional  element  of  the  operational 
Space  Station  Program,  would  perform  the  total  integrated 
payload  analysis  function.  The  PIO  would  perform  the 
prime  interface  functions  to  the  NSTS  and  would  interface 
to  the  S&T  Centers  to  accomplish  the  analytical  function 
associated  with  the  user  payloads  that  these  Centers 
represent.  For  commercial,  international, 

scientific/technology,  or  other  independent  type  users  who 
are  not,  or  choose  not,  to  be  represented  by  an  S&T 
Center,  the  PIO  would  provide  the  single  point  interface 
to  the  Space  Station  Program.  The  PIO  would  provide  full 
support  to  these  users  in  a manner  analogous  to  that 
described  previously  for  the  S&T  Centers.  The  PIO  would 
provide  the  final  verification/certification  for  the  Space 
Station  and  NSTS  Programs  that  the  payload  is  ready  to 
fly. 

RATIONALE  - This  concept  incorporates  the  best  features  of 
the  various  options  that  were  studied.  The  primary  user 
friendly  feature  and  strong  scientific,  technical  inter- 
action that  the  S&T  Centers  maintain  with  their  discipline 
colleagues  is  utilized.  In  addition,  the  centralized, 
dedicated  PIO  with  its  unique  skills  and  analytical  tools 
for  performing  the  planning,  analyses,  and  interfacing  to 
NSTS  is  established.  This  concept  provides  a friendly 
atmosphere  of  a single  interface  for  users  to  work  with, 
permits  a management  structure  that  allows  definition  of 
well  defined  roles  and  responsibilities  for  all  parties, 
and  is  an  ideal  arrangement  for  management  by  exception. 
The  negatives  to  this  concept  are  the  increase  in  the 
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INFORMATION  FLOW 


FIGURE  2-3  PRELAUNCH/POSTFLIGHT  FLOW 
FUNCTIONAL  STRUCTURE 
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number  of  organizations  involved,  which  will  increase  the 
overall  total  organizational  levels  of  interfacing  and 
management  structures.  Obviously,  with  this  will  be  some 
attendant  increase  in  cost.  However,  in  the  long  run,  the 
costs  will  probably  average  out  and  the  other  features  of 
the  concept  make  it  most  attractive. 

Documentation  System  - An  important  and  necessary  aspect  of  the 
payload  integration  process  for  the  Space  Station  program  will 
be  the  documentation  required  to  support  the  analytical , 
integration,  and  verification  efforts.  Previous  experience 
with  such  documentation  systems  were  for  payloads  to  be  flown 
on  the  NSTS,  on  Spacelab,  and  payloads  launched*  by  GLV's.  The 
main  objective  of  any  document  system  selected  for  the  Space 
Station  program  would  be  to  provide  the  proper  information  for 
payload  interfaces  with  the  NSTS  and  Space  Station  and  to 
identify  safety  issues  for  both  Space  Station  and  NSTS  opera- 
tions. The  selected  system  should  provide  traceability  of 
payload  processing  operations  and  should  aid  in  anomaly  resolu- 
tion. The  document  system  would  not  concern  itself  with 
payload  operations  other  than  safety  implications  and  interface 
compatibility  for  the  NSTS  and  Space  Station. 


A major  concern  is  that  the  documentation  system  allows  a 
single  NASA  interface  for  all  users  and  that  the  documentation 
be  as  simple  and  concise  as  possible.  The  documents  should  be 
tailored  to  the  class  of  users  (type,  size,  discipline)  and  be 
formatted  to  minimize  redundancy.  Table  2-1  is  representative 
of  the  types  of  documentation  required  during  various  phases  of 
payload  integration. 

CONCEPT  - The  documentation  system  would  utilize  the 
existing  NSTS  PIP  and  annex  system  to  document  the 
integration  of  the  Space  Station  logistics  carriers  and 
payloads  to  the  NSTS.  It  is  expected  that  the  interfaces 
between  the  Space  Station  logistics  carrier/payloads  and 
NSTS  Systems  will  be  kept  to  a minimum,  thus  allowing  the 
documentation  to  be  simplified. 
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TABLE  2-1 


DESIGN 

VERIFICATION  AND 

PHYSICAL 

INTEGRATION 

SPACE 

TRANSPORTATION 

SPACE  STA- 
TION FLIGHT 
PLANNING  AND 
IMPLEMENTATION 

□ ICD 

0 ANALYTICAL 

0 EQUIP  ASSEM 

0 FLIGHT 

(SS  AND  TRANS 1 

REQ  (ASCENT) 

PLANNING 

STRUCTURAL 

0 DATA 

THERMAL 

0 EQUIP  ASSEM 

0 FLIGHT  OPS 

PACKAGE 

REQ  (RETURN) 

SUPPORT  REQ 

0 SOFTWARE 

0 EQUIPMENT 

0 EQUIP  DISPERSAL 

0 TRAINING 

DATA 

BUILDUP 

(POSTLANDING) 

SYSTEM 

(SS  CONFIG) 

0 JOINT  SS/USER  ■ 

0 POCC 

TEST 

INTERFACE 

PREFLIGHT 

ON  ORBIT 

0 SAFETY# 

0 SAFETY# 

0 SAFETY# 

SAFETY# 

* Safety  is  an  ongoing  consideration  from  design  through  postlanding 
requiring  periodic  reviews  and  approval. 
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A separate  document  system  would  be  developed  to  cover 
payload  interfaces  and  safety  consideration  with  the  Space 
Station  systems.  Precedent  for  such  an  approach  can  be 
found  in  the  Spacelab  program.  That  program  created  a 
mission  requirement  for  payloads  documents  which 
established  the  integration,  verification,  and  safety  data 
required  for  payloads  interfacing  with  the  Spacelab.  The 
documentation  system  for  the  Space  Station  program  would 
cover  the  interfaces  with  Space  Station  Systems  such  as 
the  Data  Management  System  (DMS),  power,  thermal,  struc- 
ture, and  ELCSS.  In  addition,  verification,  training, 
safety  compliance,  payload  resource  requirements,  mass 
properties,  data  flow,  flight  definition,  and  payload 
operations  would  be  documented.  The  top  level  documen- 
tation tree  envisioned  is  shown  in  Figure  2-4. 

With  this  two  document  system  the  user  would  provide 
information  to  and  interface  with  the  S&T  Center  or  to  the 
PIO  organization  responsible  for  the  Space  Station  docu- 
ment. These  organizations  would  then  develop  the  integra- 
tion data  needed  for  the  NSTS  PIP  document  system.  All 
the  user  requirements  would  be  covered  in  one  document 
that  the  user  would  submit  to  the  PIO  or  S&T  Center. 

The  PIO  would  coordinate  the  development  of  all  documenta- 
tion and  will  develop  with  the  NSTS  the  appropriate  NSTS 
documentation.  The  PIO  would  provide  appropriate  docu- 
ments to  the  user  for  review,  again  working  through  the 
original  single  interface  point,  either  the  PIO  or  the  S&T 
Centers . 

RATIONALE  - There  are  some  concerns  with  the  friendliness 
of  a two  document  system  to  the  user.  These  concerns 
center  around  the  need  to  maintain  a single  source  point 
of  contact  for  the  users.  With  a two  document  system 
there  is  a chance  for  redundancy  in  requirements  and 
additional  interfaces.  However,  it  is  possible  to  tailor 
the  Space  Station  document  to  the  various  class  of  users 
and  assure  that  the  Space  Station  document  would  be  the 
single  point  of  contact  for  the  users.  The  PIO  would  then 
work  the  interfaces  required  with  the  NSTS  PIP  and 
annexes. 

Effective  management  would  be  able  to  be  achieved  even 
though  there  would  be  two  organizations  involved  in 
document  preparation.  Based  on  Spacelab  experience,  clear 
responsibilities  and  document  scope  could  be  established 
and  management  control  over  these  areas  could  be  put  into 
effect . 
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DOCUMENTATION 
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FIGURE  2-4  DOCUMENTATION  TREE 


The  performance  effectiveness  of  a two  document  system 
should  be  reasonably  high  due  to  the  opportunity  to 
streamline  and  tailor  the  documents  to  the  Space  Station 
program  needs.  There  is  the  potential  in  the  Space 
Station  documents  to  break  away  from  the  constraints  and 
framework  exhibited  by  the  NSTS  PIP  and  be  more  innovative 
in  formatting  the  Space  Station  document.  The  two  docu- 
ment system  will  have  to  address  the  concern  that 
important  data  or  requirements  will  be  overlooked  and  not 
be  covered  in  either  document. 

Initial  consideration  of  the  cost  of  a two  document  system 
would  indicate  potentially  higher  costs,  however,  with  the 
opportunity  to  tailor  the  Space  Station  document  (rather 
than  force  fit  into  the  NSTS  framework)  the  long  term 
costs  should  prove  to  be  lower. 

Two  modes  or  media  to  be  used  in  preparing,  distributing, 
or  transferring  the  required  Space  Station  documents  were 
considered:  the  existing  paper  system  used  on  NSTS  and 
Spacelab  Programs  and  the  concept  of  a paperless  document 
mode.  Using  a paper  document  system  similar  to  NSTS  will 
prove  to  be  an  extensive  array  of  documents  due  to  the 
complexity  and  scope  of  the  Space  Station  program.  Such  a 
large  system  will  be  cumbersome  to  utilize  efficiently. 

Electronic  data  base  document  systems  are  currently  being 
established  in  the  Space  Station  program  and  should  be 
used  to  the  greatest  extent  practical.  However, 
limitations  of  handling  data  bases  need  to  be  recognized. 
Such  a system  needs  to  be  structured  to  impose  safeguards 
on  information  transfer  and  to  establish  methods  to 
simplify  the  management  of  complex  data  bases.  Electronic 
data  bases  for  documents  should  prove  beneficial  to 
cross-checking  safety  requirements. 

Separate  NSTS  and  Space  Station  document  systems  were 
highly  rated  in  the  key  areas  of  user  friendliness,  cost 
and  management.  The  key  features  of  this  concept  are: 
the  use  of  the  separate  NSTS  system  with  which  the  Space 
Station  program  could  readily  interface;  the  opportunity 
to  tailor  the  Space  Station  program  document  to  the 
various  user  classes;  and  the  chance  to  be  innovative  in 
designing  the  format  of  the  Space  Station  document  system 
based  on  lessons  learned  from  the  NSTS  and  Spacelab 
programs . 

The  development  of  electronic  data  bases  for  documents 
should  be  expanded  as  practical  during  the  development  of 
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the  Space  Station  program,  thus  reducing  reliance  on  a 
paper  document  system. 

Physical  Integration/Deintegration 

Payload  Integration  - Physical  integration,  in  the  context  of 
user  provided  flight  experiments/equipment  for  Space  Station 
application,  is  defined  as  an  early  activity  in  overall  experi- 
ment ground  processing  where  the  actual  flight  experiment 
hardware  transitions  from  a "stand  alone"  support  structure  to 
a flight  qualified  support  structure.  This  hardware  combina- 
tion will  ultimately  be  functionally  operated  in  the 
micro-gravity  environment  of  Space  Station. 

Deintegration  is  the  post  flight  removal  of  experiment  hardware 
from  the  flight  support  element.  The  Space  Station  Program 
provided  flight  support  element  would  then  be  configured  as 
required  for  next  flight. 

Unlike  the  NSTS  Spacelab,  the  Space  Station  will  have  many 
permanent  facilities  outfitted  within  the  orbiting  laboratories 
by  IOC.  In  addition  to  these,  additional  experiment /user 
hardware  will  be  introduced  which  will  be  in  several 
categories,  such  as: 

o New  first  time/repeat  flights  of  complete  payload 
rack(s) 

o Partial  rack  complements  requiring  integration  with 
other  users  in  the  rack 

o Payload  elements  which  can  never  be  completely 

integrated  until  in  orbit  and  must  use  simulators  and 
the  telescience  loop  while  on  ground. 

o Externally  attached  payloads  mounted  on  the  Space 
Station  truss  structure. 

o Payloads  to  be  mounted  on  platforms  in  orbit. 
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The  integration  concept  must  reflect  a processing  flow  provid- 
ing minimum  time  for  experiment  hardware  and  personnel  at 
locations  away  from  the  principal  investigator /hardware  devel- 
oper sites  in  order  to  encourage  and  facilitate  Space  Station 
user  development.  The  concept  should  reflect  a flexible  flow 
enabling  easy  change  out  of  experiment  elements,  additions, 
deletions,  change  in  manifest,  early  and  late  access,  and  user 
friendly  accommodations . 


CONCEPT  - The  concept  is  to  provide  decentralized 
locations  for  experiment  physical  integration  in/on  Space 
Station  flight  support  elements.  These  locations  are 
defined  as  other  facilities  in  addition  to  the  Space 
Station  Processing  Facility  (SSPF)  located  at  Kennedy 
Space  Center.  The  candidate  decentralized  facilities  will 
be  the  D.S.  Science  and  Technology  Centers,  International 
Partner  S&T  facilities  and  select  international  or  com- 
mercial organizations  approved  for  performance  of  this 
activity  by  the  Space  Station  Program.  The  proper  assign- 
ment of  physical  integration  facility  would  be  based  on 
criteria  such  as:  availability  of  integration  facility, 
scheduling  of  flight  elements,  duration  of  experiment,  and 
user  discipline. 

This  concept  will  make  use  of  the  launch  site  Space 
Station  simulation  capability  to  perform  integrated 
payload  final  interface  functional  compatibility  tests 
prior  to  launch  package  integration  and  installation  into 
the  Orbiter.  The  launch  site  Space  Station  simulator  will 
have  been  utilized  during  the  Space  Station  assembly 
sequence  build  up  phase  and  would  continue  to  function 
during  the  mature  operations  phase.  The  integrated 
experiment  will  arrive  at  the  launch  site  and  be  removed 
from  their  transportation  equipment  in  the  SSPF  receiving 
area.  Following  visual  inspections,  the  experiment 
package  would  be  placed,  if  necessary,  in  the  appropriate 
Space  Station  simulator  device  and  functional  interfaces 
to  Space  Station  would  be  verified.  After  completion  of 
necessary  checks,  the  experiment  would  be  removed  from  the 
simulator  and  installed  in  the  appropriate  logistics 
carrier  for  launch  package  integration.  Upon  completion 
of  the  mission,  the  experiment  is  returned  to  the  SSPF 
where  it  will  be  removed  from  the  logistics  carrier  and 
either  deintegrated  in  the  SSPF  or  shipped  back  to  the  S&T 
development  center  for  final  deintegration.  The  concept 
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would  provide  for  payload  pre/post  flight  hardware  flows 
as  shown  in  Figures  2-5  and  2-6. 

RATIONALE  - The  concept  of  decentralized  physical 
integration  allows  flexibility  and  user  friendliness.  Its 
ability  to  respond  to  new  situations  should  be  excellent 
due  to  the  decentralization  of  the  hardware  buildup  with 
the  availability  of  the  engineering  expertise  and  material 
resources  at  these  sites.  This  factor  also  enhances  the 
user  friendliness  due  to  users  view  of  autonomy  during 
these  activities.  The  management  structure  will  have  well 
defined  and  clear  interfaces  and  accountability  for  both 
the  user  and  Station  organizations.  It  also  takes  advan- 
tage of  continued  use  of  Space  Station  simulators  at  the 
launch  site  which  will  be  in  place  and  functional  from  the 
Assembly  Sequence  phase  of  Space  Station.  Cost  impacts  to 
Space  Station  Program  includes  the  procurement  of  addi- 
tional flight  support  elements  to  extend  the  pipeline  to 
S&T  Centers  and  management  logistics  for  shipment  and 
configuration  control,  (ref  Appendix  0 Flight  Rack 
Processing  Analysis).  Overall  performance  should  be 
excellent  under  this  concept  with  a high  potential  for 
operational  success.  Proprietary  operations  should  also  be 
very  compatible. 

Verification  - An  important  element  of  the  physical  integration 
of  payloads  into  the  Space  Station  program  is  the  level  of  and 
approach  to  verification  testing.  The  purpose  of  final 
interface  verification  testing  is  to  demonstrate  that  the  users 
flight  equipment  and  software  are  compatible  with  the  Space 
Station  and  its  interfaces.  It  is  expected  that  user  hardware 
will  be  tested  in  the  process  of  its  buildup  to  meet  the 
specified  operations  and  interface  requirements  of  the  Space 
Station  program.  However,  it  is  desirable  to  have  a final 
ground  test,  with  realistic  Space  Station  interfaces,  to  be 
certain  the  assembly  and  previous  verification  was  done  right. 

If  inadequate  user  hardware  or  software  were  launched,  and  it 
was  found  not  to  fit,  or  otherwise  be  unacceptable  for  use  in 
the  Space  Station,  then  it  would  need  to  be  returned,  repaired, 
and  relaunched.  A ground  simulation  of  the  Space  Station 
environment  that  the  user  will  meet  would  save  him,  and  Space 
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EXPERIMENT  RACK  AND  PLATFORM  FLOW 
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FIGURE  2-5  EXPERIMENT  RACK  AND  PLATFORM  FLOW 

PREFLIGHT 


EXPERIMENT  RACK  AND  PLATFORM  FLOW 

POSTFLIGHT 


FIGURE  2-6  EXPERIMENT  RACK  AND  PLATFORM  FLOW 

POSTFLIGHT 


Station,  trouble  and  expense.  To  do  this  verification,  the 
real  characteristics  of  the  Space  Station  side  of  the  interface 
must  be  simulated  to  the  maximum  extent  feasible.  Some  of  the 
Space  Station  side  might  even  be  duplicated,  with  flight  type 
hardware.  Testing  the  user's  equipment  with  this  Space  Station 
simulator  demonstrates  to  the  user  what  resources  of  power, 
data  handling,  cooling  and  communication  the  Space  Station  will 
provide  him,  and  demonstrates  for  the  Space  Station  that  the 
experiment  will  not  degrade  or  hinder  Space  Station  system 
operations,  or  other  users. 

CONCEPT  - The  verification  testing  concept  is  to  perform 
testing  to  rack  or  attached  payload  level  on  ground  with 
simulated  Space  Station  interfaces  and  then  final  testing 
to  the  Space  Station  elements  while  on-orbit.  This  would 
require  that  the  ground  duplication  of  interfaces  to  be 
met  on  Space  Station  would  be  only  as  accurate  as  is  cost 
effective.  The  duplication  of  mechanical  interfaces  of 
sizes,  hinges,  latches  and  connectors  could  be  very 
accurate.  Duplication  of  data,  power,  thermal  and 
communications  systems  would  be  to  interface 
specification.  Other  adjacent  users  would  be  simulated  to 
only  a limited  extent.  Simulated  Space  Station  power  and 
thermal  control  system  fluctuations  would  stay  near 
nominal  levels.  The  conductive  electromagnetic 
environment  would  be  only  partly  simulated.  Systems 
software  would  be  duplicated.  The  data  bus  loading  due  to 
other  users  would  be  simulated  by  insertion  of  dummy  data 
packets.  It  is  expected  that  for  this  concept  only  minor 
or  subtle  malfunctions  would  not  be  caught.  It  is 
believed  those  could  be  worked  around  if  they  did  occur  on 
orbit. 
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RATIONALE  - The  concept  of  payload  verification  by  testing 
to  Space  Station  specifications  during  the  process  of 
buildup,  testing  to  a reasonable  level  on  the  ground,  and 
then  completing  the  testing  in  orbit  is  considered  the 
most  feasible  to  execute  at  reasonable  cost  to  the  Space 
Station  program  during  future  Space  Station  operations. 
Feasibility  is  good  because  adequate  and  mature  simulation 
of  the  various  kinds  of  user  interfaces  to  Space  Station 
will  already  exist  from  the  Space  Station  buildup  phase. 
Flexibility  for  the  user  is  good  because  the  user  can 
perform  reasonable  tests  during  his  buildup.  Final 
interface  tests  will  involve  only  minimum  interfaces  to 
the  Space  Station.  The  effect  of  adjacent  users  can  be 
reasonably  simulated  in  the  final  interface  test.  It  is 
considered  user  friendly  because  the  Space  Station 
interfaces  are  defined  and  predictable.  The  user  can  do 
whatever  tests  he  wishes  to  verify  his  payload  during 
buildup.  As  long  as  he  passes  Space  Station  safety 
standards  and  final  interface  test,  he  will  be  acceptable 
to  Space  Station.  The  final  interface  test  is  not 
intended  to  enforce  any  Space  Station  specified  internal 
quality  level  on  the  user's  equipment. 

The  effectiveness  of  transition  to  operational  use  is  high 
and  mainly  a matter  of  stabilizing  the  Space  Station 
procedures  and  documents  to  a configuration  that  minimizes 
cost  and  trouble  for  both  the  users  and  Space  Station 
program.  Management  of  final  interface  simulators  would 
remain  under  the  Space  Station  program.  The  cost  of 
simulator  facilities  would  be  already  paid  for,  with  only 
some  upgrade  needed  to  optimize  the  balance  between 
increasing  the  chance  of  catching  user  anomalies  versus 
the  cost  of  verification  equipment.  The  effectiveness  of 
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verification  performance  will  be  good,  commensurate  with 
the  quality  of  the  simulation.  The  safety  for  Space 
Station  and  user  will  be  good  because  finding  safety 
anomalies  is  the  object  of  several  reviews  and  the  final 
testing  will  be  done  by  experienced  Space  Station 
personnel . Ease  of  proprietary  operation  is  satisfactory 
because  the  users  will  need  to  reveal  only  as  much  of 
their  payload  content  as  is  required  by  safety  considera- 
tions. Any  final  interface  test  need  not  compromise  the 
security  of  user's  payload. 

Logistics  Module  Buildup  - Subsequent  to  payload  integration 
and  testing  of  the  Space  Station  flight  support  elements,  the 
next  step  in  the  physical  integration/deintegration  process  is 
the  buildup  of  the  logistics  elements,  which  include  U.S.  and 
International  Partners  proposed  elements.  The  International 
Partner  elements,  if  launched  in  the  United  States,  would 
follow  the  same  processing  flow  as  the  U.S.  element  with 
responsibilities  and  performance  being  in  accordance  with 
international  agreement. 

The  logistics  module;  unpressurized  (dry)  carrier;  propellant 
carrier;  and  fluids  and  gases  carriers  make  up  the  U.S.  logis- 
tics elements.  The  logistics  module,  which  provides  pressur- 
ized volume,  is  the  primary  vehicle  for  uplifting  and 
downlifting  (returning)  both  Space  Station  and  payload  items. 

The  dry  carrier,  propellants  carrier  and  fluids  and  gases 
carriers  are  special  purpose  carriers.  Processing  flow  of 
these  carriers  will  be  as  required  by  the  logistics  resupply  of 
Space  Station  systems.  Payload  user  items  to  fly  on  these 
carriers  would  be  recognized  as  part  of  the  overall  Space 
Station  requirement  and  integrated  into  the  normal  processing 
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flows.  Some  large  attached  payloads  will  provide  their  own 
carriers. 


CONCEPT  - The  concept  for  the  buildup  of  the  logistics 
module  (LM)  is  to  perform  the  processing  at  the  launch 
site.  The  following  are  the  major  flow  operations 
required  for  this  processing: 

1.  Handling  of  logistics  module  within  launch  site 
processing  facility  after  removal  from  the  Orbiter. 

2.  Inspection  for  visual  problems  and  of  areas 
required  by  design  element  in  requirements  and 
specifications  document. 

3.  Returned  configuration  verification  to  module 
replacement  unit  level  such  as  stowage  lockers  is 
accomplished  before  module  deintegration. 

Inventory  within  stowage  lockers  will  be 
accomplished  later  in  an  off-line  location. 

4.  Deintegration  and/or  removal  of  those  items  not 
planned  for  reflight  and  those  which  require  some 
operation  outside  of  logistics  module. 

5.  Post-flight  verification  test. 

6.  Repair  and  maintenance. 

7.  Incorporation  of  design  changes  (modification 
kits ) . 

8.  Installation  of  module  LRO's  required  by  next  Space 
Station  flight  configuration. 

9.  Installation  of  payload  user  items  (see  rack 
processing  for  flow  description  of  user  items). 

10.  Test  of  module  system.  Interface  check  to  payload 
user  items  where  required. 

11.  Recertification  of  flight  condition  of  module 
systems  per  system  provided  requirements  and 
criteria  (OMRSD) . This  would  include  any  new 
requirements  resulting  from  ground  and  flight 
problems,  trend  analyses,  life  cycle  requirements, 
etc.,  as  designated  and  required  by  sustaining 
engineering. 
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12.  Installation  of  logistics  module  into  the  transport 
vehicle  (Orbiter). 

13.  Orbiter-to-LM  interface  teats. 

RATIONALE  - Utilizing  the  Launch  site  processing  location 
reduces  the  number  of  handling  and  shipping  operations. 
Processing  time  is  reduced  by  the  amount  of  time  which 
would  be  required  for  additional  shipping  and  handling 
operations.  The  number  of  NASA  interfaces  to  LM  users  is 
reduced.  Number  of  logistics  modules  required  to  meet 
processing  flow  is  minimized  without  need  to  provide  for 
the  additional  shipping  and  handling  time  involved  with 
remote  site. 

Transition  from  development  flight  phase.  Space  Station 
Program  management,  and  ease  of  proprietary  operations 
would,  for  long-range  operational  life,  be  enhanced  by 
processing  at  launch  site  only,  as  opposed  to  multiple 
sites  processing. 

Documentation  at  the  launch  site  follows  a more  formal 
flow  and  is  less  flexible  with  respect  to  changes.  A "get 
ready  to  launch"  environment  exists  and  puts  pressure  on 
personnel  processing  hardware  to  meet  launch  goals.  The 
second  set  of  the  design  and  development  personnel  eyes 
regarding  quality  and  reliability,  which  is  inherent  in 
using  site  where  item  is  built  as  opposed  to  the  launch 
site,  is  lost. 

Close  proximity  to  logistics  holding  area  or  spares  stores 
area;  minimization  of  turnaround  time  since  shipments  in 
and  out  of  prelaunch  area  and  post- launch  (deintegration) 
areas  are  eliminated;  provide  best  flexibility  and  cost 
for  a operational  program. 

The  number  of  interfacing  locations  to  which  users  (Space 
Station  systems  and  payload/experiment)  would  need  to 
support  is  kept  to  a minimum. 

It  is  recommended  that  the  logistics  module  development 
should  emphasize:  modularity,  provisions  for  early  and 
late  user  access,  development  of  flexible  accommodations 
which  meet  maximum  user  hardware  fabrication  tolerances, 
modular  data  bases  facilitating  changes  between  mission 
flight  complements,  reverification  of  mandatory 
recertification  requirements  and  criteria,  and 
standardization  of  procedures. 
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Late  Access /Early  Removal  of  Payload  Items  - The  final  stage  of 
physical  integration  of  payloads  into  the  Space  Station  Program 
is  the  availability  of  late  access  (approximately  72  hours 
prior  to  launch)  to  the  experiments  (in  the  case  of  a returning 
payload  it  is  early  removal  from  the  Orbiter). 

The  current  configuration  of  the  Logistics  Module  (LM)  does  not 
accommodate  access  to  the  module  after  integration  is  completed 
at  the  Space  Station  processing  facility,  two  months  prior  to 
launch.  Pad  access  has  been  a requirement  of  payloads  dating 
back  to  the  days  of  Gemini.  Both  the  NASA  and  NASDA  Life 
Sciences  organizations  have  stated  a requirement  for  late 
access  at  the  pad  and  early  removal  at  landing  for  live 
biological  specimens. 

Transport  systems  to  Space  Station  need  to  be  maintained  in  a 
pressurized  environment  and  require  power  and  an  ECLSS.  The 
Orbiter  middeck  is  the  only  pad/ landing  accessible  area, 
currently  available.  Ose  of  middeck  lockers  for  transfer  of 
rodents  to  Space  Station  is  limited  to  numbers  of  animals  and 
350  gram  size.  Squirrel  monkeys  or  larger  primates,  which  are 
planned  for  experiments  in  Space  Station  cannot  be  accommodated 
in  a middeck  locker. 

Animal  holding  facilities  will  be  available  from  Spacelab  which 
could  be  utilized  as  transporters  in  the  LM  when  Space  Station 
operations  commence.  These  units  are  capable  of  maintaining 
animals  up  to  10  days. 

CONCEPT  - The  concept  for  late  access/early  removal  is  to 
provide  this  capability  through  a change  to  the 
preliminary  design  of  the  Space  Station  logistics  module. 

RATIONALE  - This  concept  might  appear  to  be  costly  to  NASA 
and  the  Space  Station,  but  in  the  long  run,  because  of  the 


2-35 


availability  of  existing  holding  facilities  and  in  terms 
of  public  opinion  for  animal  rights,  this  may  prove  the 
least  costly  to  the  program. 


Design  changes  must  consider  safety  of  entry  and  not  rely 
on  the  type  of  access  utilized  in  Spacelab;  i.e., 
suspension  on  a "Bowswain's  chair".  Timely  access  to  the 
LM  may  also  prove  to  be  a safety  issue  for  the  program, 
both  on  launch  and  landing  for  other  reasons;  i.e.,  toxic 
wastes,  contingency  power,  or  fire  suppression. 

Distribution  of  Payload  Early  Removal  Items  - For 
payloads/experiments  returning  from  orbit  that  require  early 
removal  from  the  Orbiter,  distribution  of  these  early  removal 
items  (post-flight)  must  be  considered. 

During  the  Space  Station  operational  era,  the  opportunity  is 
available  to  transfer  biological  and  nonbiological  systems  to 
the  Space  Station  0-g  environment  for  long-term  studies  and 
sampling,  to  create  systems  both  biologically,  chemically,  and 
physically,  and  to  return  such  samples  and  systems  to  the  1-g 
for  extended  analysis  by  the  user.  Though  the  systems  may  be 
altered  in  the  0-g  environment,  they  may  still  require  unique 
support  and  maintenance  during  return,  landing,  and 
post-landing  operations. 

Nonbiological  systems  may  also  require  sustained  temperature  or 
specific  gaseous-rich  environments  to  reduce  the  potential  of 
degradation  during  transit  and  return  to  the  1-g  environment. 

Carriers  were  addressed  which  would  be  required  for  downloading 
mission  waste  and  user  specimens  other  than  animal.  Because  of 
the  nature  of  wastes;  i.e.,  gases,  chemical,  radioactives, 
containment  for  transfer  from  Space  Station  and  disposal 
requirements  are  best  resolved  by  one  organization  (Space 
Station).  Carriers  for  experimental  products  should  be 
addressed  by  the  user  for  his  specific  needs. 
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CONCEPT  - The  concept  for  distribution  of  early  removal 
items  is  that  the  user  can  negotiate  with  the  Space 
Station  Program  the  extent  of  handling  and  delivery  of  the 
payload  that  Space  Station  logistics  would  provide. 

RATIONALE  - This  concept  has  been  a mode  of  operation 
through  the  NSTS  activities  and  has  proved  effective  for 
the  user.  This  combination  allows  logistics  control  of 
hardware  items  required  for  return  and  also  assists  the 
user  in  processing  and  returning  his  samples  to  his  home 
site  in  a timely  manner.  Through  a negotiated  process,  a 
face  to  face  interaction  with  the  user  is  positive  in 
avoiding  potential  for  mistakes  occurring  from  inaccurate 
assessment  of  requirements  from  a user  document. 

Arguments  in  favor  of  this  concept  are  that  the  Space 
Station  Program  must  provide  logistics  functions  at  the 
landing  site  to  handle  the  Space  Station  logistics 
carriers  and  the  additional  costs  for  handling  and 
delivering  as  negotiated  user  items  requiring  early 
removal  would  represent  only  minor  additional  cost  to  the 
Space  Station  Program.  This  concept  would  be  friendly  to 
the  user,  since  it  would  allow  negotiation  for  services 
that  the  user  sees  as  necessary  to  early  removal  item  pro- 
cessing. Negotiation  of  services  should  be  achieved  at 
the  execution  level. 


Support  Functions 


Recertification  of  Flight  Hardware  - An  area  of  support 
required  for  the  pre/post-flight  operation  processes  is  the 
recertification  of  payload  processing  flight  hardware. 


Recertification  is  the  process  by  which  acceptability  for  next 
use  of  flight  hardware  is  verified.  Recertification  verifies 
that  performance  of  all  activities  such  as,  but  not  limited  to, 
inspections,  tests,  maintenance,  servicing,  calibration, 
replacement  of  limited  life  or  failed  parts  and  components, 
etc.,  of  Space  Station  hardware  and  software  have  been  accom- 
plished satisfactorily. 


2-37 


Criteria  for  inspections , tests,  maintenance,  servicing, 
calibration,  replacement,  etc.,  of  Space  Station  systems 
hardware  and  software  between  flight  and/or  on  a periodic  basis 
are  key  factors  required  for  success  of  long  life  operations 
and  cost  management.  The  criteria  and  procedures  need  to  be  in 
place  for  first  flight.  Update  as  changes  are  made  and 
problems  occur  during  the  development  flights  should  be 
accomplished  in  such  a manner  as  to  support  the  transition  of 
Space  Station  from  development  to  operational  status.  Emphasis 
in  this  area  and  coordination  with  logistics  on  sparing  and 
reverification  is  an  essential  part  of  the  proper  selection  of 
spares  for  the  long  life  of  Space  Station.  A separate  method 
of  providing  management  visibility  and  control  of  the 
recertification  criteria  and  specifications  is  needed.  The 
Sustaining  Engineering  Organization  should  have  responsibility 
for  overall  management  of  recertification  with  both  flight  and 
ground  operations  providing  timely  implementation  and 
information  on  results  of  recertification  and  comparison  trends 
versus  problems  experienced. 

For  international  users,  the  NASA  problem  report  and  corrective 
action  system  will  provide  visibility  into  station  problems  on 
his  provided  hardware.  NASA  Space  Station  sustaining  engineer- 
ing will  request  corrective  action  where  overall  Space  Station 
systems  performance  is  impacted. 

For  U.S.  provided  hardware  and  software,  the  tracking  and 
reporting  on  problems  will  be  within  the  NASA  problem  report 
and  corrective  action  system.  Responsibility  for  assessing, 
controlling  requirements,  and  evaluating  effectiveness  of 
recertification  of  Space  Station  system  hardware  is  assumed  to 
be  a sustaining  engineering  function. 
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CONCEPT  - The  concept  for  recertification  entails  the 
management  and  control  of  the  recertification  requirements 
by  the  Space  Station  sustaining  engineering  organization 
and  the  implementation  of  these  requirements  by  the  launch 
site  organization. 

The  major  functions  of  the  recertification  concept  are  as 
follows: 


o Maintain  and  update  recertification  criteria.  Maintain 
and  update  procedures  for  inspections,  tests,  and 
calibrations.  Maintain  and  update  historical  records 
as  required  by  specification  and  requirements  documents 
and  quality  and  reliability  and  safety  documents  where 
applicable. 

o Verify  that  records  indicating  required  tests, 

inspections,  maintenance,  calibration,  replacements, 
rework,  modifications,  etc.,  have  been  accomplished. 
Establish  and  maintain  standard  operation  procedures 
for  recertification. Initiate  and  maintain  certification 
records . 

The  concept  to  perform  recertification  of  flight  hardware 
at  the  launch  site  includes  the  following  features: 


- All  documentation,  certifications,  tracking  and 
reporting,  records  of  certification  are 
responsibility  of  launch  site. 

- Launch  Center  certifies  recertification  status  at 
flight  readiness  reviews. 

Space  Station  sustaining  engineering  organization 
provides  changes  in  criteria  and  specifications 
needed  for  certification  as  evidenced  by 
performance,  via  formal  change  request  process. 

RATIONALE  - Performance  of  recertification  of  flight 
hardware  at  the  launch  site  involves  the  following 
attributes: 

o This  concept  provides  a central  source  for  documents  - 
problem  reports,  test  reports,  data  packages,  etc., 
needed  for  recertification.  The  most  experienced  test 
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personnel  during  the  operational  phase  will  be  at  the 
Launch  Center. 

o Recertification  before  higher  level  integration  is  a 
constraint  to  most  milestones  and  status  needs  to  be 
known  for  work  planning  impact  assessment. 

o Launch  operations  personnel  are  more  sensitive  to 
immediate  processing  flow  schedule  priorities  than 
independent  integrator . 

o The  major  factor  favoring  the  concept  of  Launch  Center 
recertification  is  that  records,  hardware,  and  problem 
resolution  experience  are  more  concentrated  in  the 
Launch  Center  during  the  operational  phase. 

PBer  Support  Facilities  - Pre/post-flight  operations  involve 
user  support  facilities  at  the  launch/ landing  site.  The  NASDA 
have  indicated  requirements  for  facility  space  for  final 
integration  and  checkout  of  their  ELM,  plus  animal  handling 
facilities  and  phytotrons.  D.S.  users  in  the  Microgravity  and 
Materials  Processing  and  Life  Sciences  disciplines  will  also 
require  facilities  supporting  pre/postflight  operations  involv 
ing  biological s and  crew  baselining. 

A crew  Baseline  Data  Collection  Facility  (BDCF),  will  be 
required  at  the  launch  site  and  the  landing  sites  (Dryden  and 
Kennedy  Space  Center).  Such  facilities  with  their  complement 
of  equipment,  must  be  in  place  prior  to  launch  and  must  be 
available  immediately  at  crew  landing.  Deconditioning,  depen- 
dent on  the  function,  can  occur  within  10-20  minutes  after 
reintroduction  to  1-g.  Current  Life  Sciences  planning  will 
closely  analyze  all  mission  crew  physiological  changes  in  an 
effort  to  determine  the  potential  of  the  long  term  Humans  In 
Space  Program.  A BDCF  would  be  a long  term  use  facility. 

Similarly,  the  science  community  addressing  functions  in 
non-human  systems  will  require  facilities  for  immediate  post 
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flight  analysis  and  testing  of  live  specimens.  Animal  handling 
facilities  of  this  type  exists  for  the  Spacelab  program  and 
could  accommodate  pre/ post-launch  and  early  access /removal 
activities  for  the  Space  Station. 

It  is  assumed  that  NASA  will  maintain  the  same  requirements  for 
NASDA  and/or  ESA  biological  specimens  as  those  placed  on  their 
U.S.  experimenters.  This  issue  must  be  addressed  if  a single 
transport  containment  system  is  used  for  all  animals  as  indi- 
cated by  NASDA. 


Other  potential  preflight  operations  requiring  unique  support 
would  include  sterilization  (autoclave,  ethylene  oxide,  and 
irradiation),  system  evacuation  and  pressurization,  incubation. 
These  capabilities  could  potentially  be  procured. 


CONCEPTS  - No  clear  choice  among  the  concepts  considered 
for  user  support  facilities  emerged  from  the  evaluation 
process,  therefore  a description  and  assessment  of  each 
concept  was  presented. 

A concept  of  the  user  contracting  for  off -site  facilities 
allows  the  user  to  contract  for  a facility  in  which  he  may 
perform  any  prelaunch  activities  or  to  contract  for 
services,  i.e.,  sterilization/  cleaning  activities  cited. 
If  NASA  dictates  this  must  be  the  mode  of  operation,  there 
would  have  to  be  some  assurance  that  such  facilities  an/or 
services  exist  within  the  launch  area*  Additionally,  this 
implies  that  hardware  must  be  moved  from  the  off -site  area 
to  the  launch  processing  facility.  The  latter  activity 
places  an  added  cost  on  the  user  or  potentially  on  NASA, 
depending  who  transfers  equipment  from  off-site  to  the 
launch  site. 

The  off -site  facility  for  the  BDCF  equates  to  no  facility 
at  all  because  of  the  degradation  in  performance;  i.e., 
the  requirement  for  ASAP  crew  access  post  landing.  For 
animals,  off -site  facilities  may  not  be  capable  of 
accommodating  stringent  housing  requirements;  restricted 
public  visibility  and  access;  and  contingency  launch 
requirements.  Off -site  facilities  may,  in  fact  result  in 
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added  cost  to  NASA,  may  result  in  a management  headache, 
and  do  not  allow  the  flexibility  necessary  for  late/early 
access  and  contingency  delays. 

A concept  of  a facility  provided  at  the  launch  site  with  a 
rental  fee  to  the  user  allows  flexibility  because  of  the 
nearness  to  the  launch  site.  It  also  eliminates  the 
potential  that  a commercial  facility  may  simply  not 
continue  to  exist  for  the  operational  lifetime  of  Space 
Station.  It  eliminates  any  contract  or  legal  obligations 
NASA  may  face  in  stating  that  the  user  roust  find  a 
facility  off-site,  i.e.,  if  there  were  potentially 
multiple  contenders  to  offer  services.  It  would  allow 
easier  configuration  for  a dedicated  user  i.e.,  the  BDCF 
or  animal  handling.  It  also  maintains  NASA  requirements, 
i.e.,  American  Association  for  Laboratory  Animal 
Certification  (AALAC)  under  government  control  and 
surveillance.  For  the  animal  handling  capabilities,  this 
is  feasible;  such  facilities  do  exist  and  support  SL 
activities . 

A concept  of  providing  a trailer  lot  with  power  hook-ups 
to  the  user  at  the  launch  site  was  reviewed.  This  is 
viable  for  short  term  proprietary  activities.  It  would 
not  be  viable  for  rack  integration,  BDCF  activities,  or 
animal  maintenance.  Facility  support  is  dependent  on 
application  requirements. 


2 . 3 OTHER  OPTIONS 

2.3.1  Summary  of  Options  Considered 

The  Space  Station  Operations  Task  Force  Ground  Operations  Panel 
(Pre/Post-Flight  Subpanel)  developed  and  evaluated  options  for 
the  Space  Station  operational  phase.  NSTS  involvement  included 
organizational  interfaces  and  management  methods  of  and  between 
users.  Space  Station,  and  NSTS.  Three  options  were  developed 
and  evaluated.  Payload  analytical  operations  and  documentation 
requirements  were  reviewed  for  who  performs,  controls,  and 
develops  (four  options).  Physical  integration  included  location 
of  and  who  accomplishes  performance  of  rack  hardware/software 
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performed  (two  options);  location  of  and  level  of  verification 
testing  (four  options);  location  and  performance  of  deinte- 
gration (four  options);  flight  hardware  i.e.,  logistics  module, 
racks,  and  pallet,  recertification  (three  options);  delivery  and 
distribution  of  post-flight  early  removal  items  (three  options); 
provisions  for  late  access/early  removal  (supportability ) (three 
options);  analyses  and  integration  (two  options);  and  how  and 
where  user  support  facilities  are  provided  (three  options). 

Major  consideration  was  given  to  buildup  of  racks  containing 
experiments,  supplies,  and  operating  system  units  that  are  to  be 
placed  inside  the  pressurized  areas.  Most  of  the  references  are 
to  these  racks.  Strong  consideration  was  also  given  to  the  pre 
and  post-flight  operations  for  experiments  and  operating  systems 
that  are  attached  externally  on  the  nonpressurized  areas  of 
Space  Station.  The  pre  and  post-flight  operations  for  these 
external  attached  items  are  the  same  as  for  the  racks.  The 
pre/post  flight  operations  for  Space  Station  Platforms  will  be 
essentially  the  same  as  for  other  Space  Station  payloads,  except 
that  the  GSFC  has  been  delegated  by  the  Space  Station  Program 
the  responsibility  for  the  integration  and  verification 
activities  for  these  platforms.  The  ground  operations 
associated  with  Space  Station  platforms  are  discussed  in  more 
detail  in  Appendix  D. 

NSTS  involvement  including  organizational  interfaces  and  manage- 
ment methods  of  and  between  users.  Space  Station,  and  NSTS 
options  were  developed  and  evaluated. 

Option  1 Current  Spacelab  Model  - A Payload  Integration 
Organization  (PIO)  manages  interfaces  to  Space  Station  and 
NSTS  users.  The  Space  Station  system  organization  accesses 
and  insures  or  "buys  off"  on  Space  Station  interface 
compatibility  and  safety.  STS  works  the  NSTS  side 
interface,  accepts  inputs  from  Space  Station  on  Space 
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Station  interface  and  safety  and  from  PIO  on  payloads.  NSTS 
current  PIP  Annex  documents  are  used  to  document  system  where 
applicable. 

Option  2 The  STS  and  Space  Station  Management  Teams  and 
functions  are  combined  and  merged  into  one  group.  This 
group  manages  and  controls  all  aspects  of  both  Space 
Station  and  NSTS  requirements,  verification,  documentation, 
etc.  The  combined  group  interfaces  directly  with  user  to 
obtain  requirements,  work  the  incompatibilities,  problems, 
documentation , etc . 

Option  3 This  modified  model  utilizes  central  Space 
Station  (PIO)  teams  to  interface  with  and  provide  inputs  to 
NSTS  and  user.  The  NSTS  uses  presently  defined  PIP  Annexes 
to  document  and  control  operations. 

Payload  analyses  covering  all  aspects  of  flight  and  integration 
are  performed  as  part  of  analytical  activities.  User  interface 
analyses  are  performed  on  (a)  payload  relation  to  NSTS,  (b) 
payload  relation  to  logistic  module,  and  (c)  payload  relation  to 
Space  Station. 

Option  1 User  autonomy  wherein  the  user  reviews  all 
requirements  for  interfacing  and  provides  analysis  results 
to  Space  Station  organizations. 

Option  2 A user  representative  (a  science  and  technology 
organization)  inputs  and  coordinates  interface  aspects  with 
the  Space  Station  management  organization.  The  user  works 
with  the  Science  and  Technology  Center  on  interfaces  to 
Space  Station  and  STS. 

Option  3 The  user  works  with  and  through  a defined  Space 
Station  element  organization  as  a payload  integration 
organization  which  interfaces  to  Space  Station  management. 

Option  4 User  provides  analysis  to  a payload  integration 
organization  or  Science  and  Technology  Center  which  inputs 
to  a PIO. 

Supporting  documentation  system  for  analyses  includes  experiment 
requirement  documents.  Program  Implementation  Plan  (Annexes), 
Safety  documents,  ground  integration  requirements  documents. 
Interface  Control  Documents,  and  verification  documents. 
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System  options  for  developing,  controlling,  using  documents  are 
as  follows: 

Option  1 The  NSTS  PIP  Annex  would  be  used  for  both  Space 
Station  and  NSTS  documentation. 

Option  2 The  NSTS  continues  to  use  PIP  Annex  system  for 
NSTS  only.  Space  Station  uses  a separate  documentation 
system  compatible  with  NSTS  requirements  which  only 
requires  single  input  to  Space  Station  from  user. 

Option  3 NSTS  documentation  system  is  modified  to  meet 
Space  Station  requirements  and  combined  with  Space  Station 
documentation . 

Option  4 Guidelines  are  defined  and  provided  to  users  who 
prepare  the  interface  documents. 

Physical  integration  including  hardware  buildup  locations, 
logistics  elements  buildup,  methods  of  performing  verification 
testing  in  reference  to  hardware  to  be  used,  deintegration 
location  and  flow  of  hardware,  recertification  of  flown  hard- 
ware, distribution  and  shipment  of  early  removal  items,  support- 
ability  to  late  access/early  removal,  and  user  support  facili- 
ties options  were  developed. 


Payload  (attached  or  rack  mounted)  hardware/software 
integration/deintegration  options  follow: 

Option  1 The  Space  Station  support  elements  would  be  held 
at  KSC.  Hardware  to  be  integrated  into  the  racks  would  be 
shipped  to  KSC.  KSC  with  user  support  would  install  user 
hardware . 

Option  2 Science  and  Technology  Centers  who  develop  and 
verify  experiments  would  build  up  complete  experiment 
element  complements  for  delivery  to  the  carrier  site  where 
elements  are  to  be  installed.  The  S&T  Center  tests 
elements  against  interface  simulator. 

Option  3 Commercial  facility  and/or  Science  and  Technology 
Center,  and  Space  Station  element  processing  site  buildup 
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Space  Station  support  elements.  Final  integrated  element 
to  Space  Station  interface  checkout  is  accomplished  at  Work 
Package  (WP)  site. 

Option  4 Commercial  facility  and/or  Science  and  Technology 
Center,  and  Space  Station  element  processing  site  buildup 
Space  Station  support  elements.  Final  integrated  element 
to  Space  Station  interface  checkout  is  accomplished  at 
launch  site. 


Location  for  logistics  module  buildup  included  options  to: 

Option  1 Perform  logistics  module  preparations  off  site 
and  deliver  it  to  the  launch  site.  Only  late  stowage  would 
be  installed  at  launch  site. 

Option  2 Preparation  of  logistics  module  for  flight  is 
performed  at  launch  site. 

Verification  location  and  level  of  testing  options  considered 
are  as  follows: 

Option  1 The  hardware  being  integrated  is  tested  on  ground 
in  a "full-up"  mode  with  high  fidelity  simulators  used  to 
simulate  the  Space  Station  system. 

Option  2 Testing  is  accomplished  at  rack  or  attached 
payload  level  on  the  ground  with  minimum  interface 
simulators.  Complete  system  tests  are  only  performed  on 
orbit  after  mating  with  Space  Station  elements. 

Option  3 All  interface  and  system  testing  is  performed 
while  the  hardware  is  on  orbit  with  no  rack  or  integrated 
ground  testing. 

Option  4 The  data  system  and  software  testing  is 
accomplished  on  ground  using  the  Data  Management  System 
(DMS)  on  orbit  system  through  up  links  and  down  links. 
Physical  interfaces  are  verified  with  ground  master  gauge. 

Flight  hardware  recertification  is  the  process  by  which  accept- 
ability for  next  use  is  certified.  Three  options  for  hardware 
recertification  were  considered  with  sustaining  engineering  to 
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have  responsibility  for  management  and  control  of  requirements 
under  all  options*  TJie  three  options  assessed  are  as  follows: 


Option  1 Launch  center  recertifies  all  program  provided 
flight  hardware. 

Option  2 A commercial  integrator  recertifies  all  program 
provided  flight  hardware. 

Option  3 Integrator  (ie.  S&T  Center,  International 
Partner,  etc.)  recertifies  all  program  provided  flight 
hardware  just  prior  to  installing  experiment  hardware. 


m 

Post-flight  distribution  of  early  removal  items  includes 
removal,  packing  and  shipping,  and  turnover  to  the  users  of 
items  which  are  time  critical. 


Three  options  involving  shipping  and  turnover  performance  were 
developed  and  are  as  follows: 

Option  1 Space  Station  delivers  all  early  removal  items 
such  as  films,  biologicals,  experiment  products,  etc.  to 
logistics  at  the  landing  site.  Logistics  performs  shipping 
and  transfer  to  user  operations. 

Option  2 Space  Station  delivers  early  removal  items  to 
customer  at  the  landing  site.  User  handles  all  shipping 
associated  activities  after  items  are  directly  delivered  to 
him. 

Option  3 Space  Station  delivers  those  items  to  logistics 
which  ships  for  the  users  to  designated  location  and/or 
users  pickup  and  ship  items  which  they  identify  must  be 
handled  by  the  user  at  the  landing  site. 

Providing  of  capability  enabling  or  supporting  late  access/early 
removal  options  are  as  follows: 

Option  1 Program  makes  no  provisions  for  late  access  or 
early  removal . 

Option  2 Provide  access  to  the  logistics  module  through  a 
design  change,  including  addition  of  ECLSS. 
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Option  3 Program  provides  special  payload  bay  carriers  to 
accommodate  late  access  and  early  removal  requirements. 


Dser  support  facilities  provisions  within  launch  area  including 
on  site  and  off  site  considerations  were  evaluated.  Options 
selected  for  detailed  assessment  are  as  follows: 

Option  1 The  user  would  contract  with  an  off  launch  site 
facility  for  support  to  process  his  payload.  The 
contractor  providing  the  off  launch  site  facility  delivers 
payload  to  launch  site  (pre  mission)  and  removes  payload 
from  deintegration  location  (post  mission). 

Option  2 Launch  site  provides  user  a facility  where  he  can 
perform  pre  and  post  mission  processing.  Charges  to  user 
for  support  and  the  schedule  for  facility  support  period 
would  be  negotiated  with  launch  center. 

Option  3 Launch  center  areas  where  user  can  park  and 
operate  his  payload  support  vehicle  such  as  trailer  or  van 
are  provided  by  NASA. 

2.3.2  Details  of  Options  Considered 


NATIONAL  SPACE  TRANSPORTATION  SYSTEM  (NSTS)  INVOLVEMENT 


Concepts  for  Space  Station  involvement  with  the  NSTS  are 
focussed  on  how  the  relative  roles,  missions,  and  organizational 
interface  are  partitioned  and  what  lines  of  communications  are 
established  between  the  involved  elements  of  Space  Station, 
users  of  Space  Station,  and  NSTS.  The  three  basic  models 
considered  are  identified  as  (1)  current  Spacelab/NSTS  model, 

(2)  a combined  Space  Station  and  NSTS  and,  (3)  modified 
approach.  A third  organizational  element  on  the  NASA  side  of 
the  user  interface  is  the  Payload  Integration  Organization 
(PIO).  The  models  treat  variations  on  the  relationships  among 
these  elements. 
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Option  1.  Current  Spacelab/NSTS  Model  - Even  though  the 
Spacelab  Program  is  considered  an  integral  part  of  the  NSTS, 
there  is  a separate,  identifiable  organization  of  the  Spacelab 
Program  and  also  a separate  identifiable  organization  that 
performs  the  function  of  a PIO.  The  PIO  function  is  to  provide 
all  the  necessary  contact  with  users  in  identifying  requirements 
for  Spacelab  and  NSTS  and  then  arranging  and  integrating  the 
necessary  ground  and  flight  accommodations  for  the  mission.  A 
significant  feature  in  this  model  is  that  the  PIO  interfaces 
directly  with  both  Spacelab  and  NSTS  for  accommodations  plan- 
ning, and  additionally,  Spacelab  would  also  coordinate  select 
activities  with  the  NSTS.  This  approach  could  also  be  applied 
to  the  Space  Station/NSTS  Programs,  the  key  feature  being  a 
separate  PIO  function  able  to  interface  independently  with 
either  Space  Station  or  NSTS. 

Analysis  - The  feasibility  of  this  option  has  been  established 
by  the  current  MSFC  Spacelab  Payload  Program  since  this  is  the 
approach  utilized  and  it  works.  The  flexibility  of  this  option 
in  response  to  changes  is  good  since  there  is  a single  point 
contact  to  users  and  to  the  NSTS  for  working  changes  and  the  PIO 
is  the  focal  point  for  performance  of  all  integration  activi- 
ties. The  user  friendliness  of  this  option  was  rated  rather 
poorly  by  some  members  who  had  experiences  in  the  early  Spacelab 
missions.  However,  the  PIO  provides  a single  interface  for 
users  and  performs  all  functions  for  the  user  in  relation  to  the 
NSTS  thus  letting  the  user  stay  out  of  that  loop. 

The  effectiveness  of  the  option  was  rated  overall  as  average. 

The  major  detractors  being  the  number  of  organizations  involved 
with  the  attendant  complexity  in  management  interfaces.  There 
is  also  potential  for  duplication  of  functions  between  the  PIO 
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and  Space  Station  organizations.  Costs  were  judged  to  be 
probably  highest  for  this  option. 

Overall  this  option  was  rated  last  by  the  Subpanel.  This  rating 
was  based  primarily  on  the  perceived  lack  of  user  friendliness 
and  the  complexity  of  the  management  structure  with  potential 
for  high  costs. 

Option  2.  Combined  Space  Station  and  NSTS  Model  - The  combined 
Space  Station  and  NSTS  model  would  appear  to  the  user  to  be  a 
single  organization  providing  all  the  necessary  services  for 
Space  Station  missions.  The  Space  Station/NSTS  points  of 
contact  to  the  user  would  provide  all  needed  information, 
collect  all  known  user  requirements,  perform  required  Space 
Station  and  NSTS  analytical  integration,  and  commit  for  the 
Space  Station/NSTS  organization  all  agreed  accommodations. 
Additionally,  the  single  organization  would  perform  all 
necessary  certifications  for  both  Space  Station  and  NSTS  flight 
worthiness . 

Analysis  - The  feasibility  of  this  option  was  rated  very  low. 
Combining  the  Space  Station  into  the  NSTS  at  the  IOC  time  frame 
did  not  appear  to  be  practical  or  feasible  due  to  fact  that  with 
two  large  programs  of  their  magnitude  that  their  combination 
could  not  be  worked  out.  Such  a large  organization  was  not  felt 
to  be  user  friendly  due  both  to  its  size  and  potential  preoccu- 
pation with  performing  their  prime  functions. 

The  effectiveness  was  rated  as  good  to  excellent.  This  judge- 
ment was  based  primarily  on  the  combining  of  the  organizations, 
less  management  structure,  reduced  changes  for  duplication  of 
efforts  compared  to  separate  organizations,  and  the  hoped  for 
reduced  costs  by  going  to  a single  organization.  In  terms  of 
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management  efficiency  and  safety  it  was  judged  superior  due  to 
having  a single  interface  and  consolidation  of  all  related 
activities  under  a single  management. 

The  option  was  rated  second  by  the  Subpanel . The  major  strong 
points  were  the  single  organization,  reduced  chances  for  redun- 
dancy of  efforts,  and  lower  costs.  The  major  weaknesses  are  the 
lack  of  flexibility,  feasibility  and  the  feeling  that  such  an 
organization  would  not  be  very  user  friendly. 

Option  3.  Modified  Model  - The  modified  model  would  provide  a 
separation  between  the  Space  Station  and  NSTS  Programs,  but  the 
PIO  function  would  be  an  integral  part  of  the  Space  Station 
organization.  The  PIO  would  perform  for  the  Space  Station 
Program  all  the  planning  and  implementation  of  a Space  Station 
incremental  mission.  In  this  model,  as  in  Option  l.the  PIO 
would  serve  as  the  user  point  of  contact.  The  PIO  function 
would  interface  to  the  NSTS  for  defining  requirements  and 
arranging  user  accommodations.  A single  line  of  communication 
between  the  Space  Station  and  NSTS  is  provided  to  carry  all 
necessary  communications  for  either  Space  Station  unique 
functions  or  Space  Station  users ' s functions . 

Analysis  - This  option  was  considered  very  feasible  and 
desirable.  Its  flexibility  in  responding  to  changes  will  be 
good  since  there  is  a single  organization  working  and  focusing 
all  changes.  The  PIO  would  again  be  the  single  interface  to  the 
user  and  the  single  interface  into  the  NSTS,  thus  hopefully, 
achieving  user  friendliness.  As  in  Option  1 the  PIO  would 
perform  all  integrated  analytical  integration  functions  for 
users  and  NSTS. 
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The  overall  effectiveness  of  this  option  was  rated  superior  for 
it  consolidates  under  a single  management  all  of  the  activities 
associated  with  implementing  a Space  Station  mission.  This 
attribute  will  result  in  reduced  management  interfaces,  reduced 
probability  of  redundant  efforts,  increased  management  effi- 
ciency, and  reduced  overall  costs.  Safety  should  be  enhanced 
since  all  activities  are  focused  in  a single  entity. 

This  option  was  rated  best  by  the  Subpanel.  Prime  reasons  were 
the  single  Space  Station  organization  to  carry  out  all  mission 
function,  single  point  interface  to  both  the  users  and  the  NSTS 
and  great  potential  for  reducing  cost  compared  to  the  other 
options.  The  only  significant  distraction  is,  as  compared  to 
Option  2,  a separate  organization  is  required  for  operation  of 
the  NSTS.  However,  we  really  feel  this  separation  is  required 
and  realistic. 

Conclusions  and  Recommendations 

The  recommended  option  for  the  NSTS  involvement  is  Option  3,  the 
Modified  Model,  in  which  the  PIO  is  integrated  into  the  Space 
Station  Program.  This  means  the  Space  Station  Program  would 
have  one  organizational  element,  i.e.,  PIO,  performing  and 
accountable  for  Space  Station  incremental  missions.  The  NSTS 
would  remain  as  it  is  presently  structured  and  only  perform  for 
Space  Station  missions  the  functions  it  now  performs  for  all 
NSTS  flights. 

The  prime  rationale  for  this  recommendation  is  the  consolidation 
into  a single  organizational  element  with  in  the  Space  Station 
Program  for  all  Space  Station  activities  and  responsibility  for 
Space  Station  mission.  As  noted  under  analysis  of  Option  3 this 
should  result  in  increased  management  effectiveness  and  reduced 
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cost*  At  the  same  time  this  approach  provides  clear  and 
straightforward  interfaces  for  the  users  and  the  NSTS,  allowing 
clear  definition  of  roles  and  responsibilities  in  relation  to 
these  elements.  With  all  factors  considered  this  option  came 
out  the  overwhelming  choice  of  the  Subpanel. 

The  Modified  Model  was  rated  best  in  the  Subpanel  assessment. 

The  other  two  models  were  about  equal  in  their  lower  rating. 

The  significant  detractors  of  Option  1,  Spacelab/NSTS  Model, 
were  less  user  friendly  and  higher  costs  for  the  user.  The 
multiple  organizational  interfaces  for  the  PIO  function  was 
viewed  as  adding  complexity,  effort,  risk  of  error,  and 
increased  costs.  The  detractors  in  Option  2,  combined  Space 
Station  and  NSTS,  related  to  feasibility  and  transition  into 
mature  operations.  The  feasibility  of  merging  two  large 
programs,  each  with  significant  but  diverse  objectives,  was 
viewed  as  being  convenient  for  the  user,  but  somewhat  difficult 
to  achieve. 

Accountability  of  actions  and  costs  in  the  "conglomerate" 
approach  was  a concern  as  well  as  concern  for  a stifling  of 
advocacy  for  resources  if  Space  Station  and  NSTS,  with  their 
diverse  objectives,  were  joined  as  one  Program. 

The  modified  model  was  favorably  rated  by  the  Subpanel  due  to 
the  clear  separation  of  Space  Station  and  NSTS  organizations  and 
the  minimum  number  of  organizational  interfaces  involved.  The 
user  has  the  advantage  of  working  with  an  identifiable  PIO 
function  within  the  Space  Station  organization  and  there  is  a 
single  line  of  dialog  between  the  Space  Station  and  NSTS 
organization.  Transition  into  the  mature  operations  phase  is 
expected  to  be  easy  due  to  Phase  C/D  implementations.  Accounta- 
bility for  actions  taken  and  costs  incurred  will  be  clear. 
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PAYLOAD  ANALYSIS 


Oser  Interfaces  Analyses  - A significant  area  that  the  Subpanel 
thought  needed  a detailed  review  and  analyses  was  one  dealing 
with  the  organizational  structure  and  thus,  the  users  interface 
for  accomplishing  the  payload  integration  analyses  functions. 

The  functions  addressed  in  relation  to  the  user  in  the 
activities  required  for  payload  integration  are  those  such  as 
defining  the  user's  requirements,  establishing  of  his  hardware 
interfaces  to  the  Space  Station,  performing  of  the  interface 
compatibility  and  safety  analysis  of  his  hardware  to  the  Space 
Station,  to  the  Space  Station  launch  carrier;  i.e.,  logistics 
module  or  some  other  carrier,  and  with  the  NSTS.  The 
accomplishment  of  this  analytical  integration  function  requires, 
initially,  the  inputs  from  the  user  of  his  requirements, 
followed  by  review  and  concurrence  by  him  of  the  resources  he 
has  been  allocated  and  finally  support  to  and  participation  in 
the  required  Space  Station  payload  safety  and  verification 
program.  Thus,  the  user  will  have  a long  term  and  potentially 
extensive  interaction  with  whoever  performs  the  integrated 
analytical  integration  function. 

The  scope  of  the  payload  integration  analyses  process  that  the 
Subpanel  addressed  did  not  include  the  selection  and  manifesting 
of  the  users.  The  process  considered  begins  subsequent  to  the 
selection  and  manifesting  of  a user  to  a Space  Station  mission 
segment  and  the  supporting  NSTS  flight  and  carries  through  to 
the  return  of  his  products  and/or  hardware  from  orbit.  The 
period  of  the  user's  involvement  in  most  cases  will  be  of  a 
multi-year's  time  span.  The  degree  of  the  user's  involvement 
will  be  a function  of  his  payloads  operational  and  functional 
interfaces  to  the  Space  Station,  the  NSTS  payload  carrier,  and 
to  the  NSTS  launch  vehicle.  For  the  simple,  highly  autonomous 
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payload  with  few  or  very  benign  interfaces,  the  process  will 
mainly  be  concerned  with  the  safety  aspects  of  the  hardware. 
However,  for  the  complex,  highly  Space  Station  interactive 
payloads,  the  process  will  be  very  detailed  and  demand  a high 
involvement  by  the  user.  The  system  set  up  for  accomplishing 
the  payload  analyses  process  must  recognize  this  and  be  flexible 
enough  to  respond  appropriately,  only  demanding  from  and  involv- 
ing the  users  to  the  minimal  extent  practical . 

The  Subpanel  assessed  and  evaluated  four  options,  which  were 
felt  to  cover  the  spectrum  of  how  one  could  set  up  and  interface 
the  users  in  the  payload  analyses  process.  Obviously,  there  are 
a number  of  variations  on  any  of  these  options  that  could  and 
should  be  considered  in  the  final  implementation;  however,  we 
limited  our  assessment  to  these  prime  four  as  we  believe  they 
identify  and  evaluate  the  critical  factors  concerning  the  user's 
interfaces  to  the  payload  analyses  process. 

Option  1.  User  Autonomy  - This  option,  in  a very  high  level 
diagrammatic  form,  is  shown  in  Figure  2-7.  In  this  option,  the 
user  would  be  provided  the  detailed  set  of  requirements  that  he 
must  comply  with  to  participate  with  and  fly  on  the  Space 
Station  and  the  NSTS.  The  user  would  then  perform  all  the 
analyses,  test,  and  provide  documentation  to  prove  and  certify 
to  both  the  Space  Station  and  NSTS  organizations  that  he  is  safe 
and  interface  compatible  with  the  two  systems.  In  this  option, 
the  Space  Station  and  NSTS  organizations  would  each  perform 
their  integrated  payload  analyses  functions.  This  option 
provides  the  user  the  highest  degree  of  autonomy  to  perform  his 
job  with  the  minimum  amount  of  interaction  with  the  Space 
Station  and  NSTS  and  to  provide  them  a finished  product. 
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FIGURE  2-7  USER  AUTONOMY 
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Analysis  - This  option  was  judged  to  present  a relatively 
advanced  concept  from  the  way  we  have  been  doing  business.  The 
feasibility  of  this  option  was  not  considered  very  high  due  to 
fact  that  many  of  the  users  will  not  have  the  capability  to 
perform  the  total  analysis  job.  The  option,  though,  does  offer 
maximum  flexibility  for  the  user  to  get  the  job  done  in  the  most 
efficient  manner,  however,  it  limits  the  amount  of  flexibility 
of  the  Space  Station  organization  as  it  must  depend  on  users  for 
all  analyses.  It  was  considered  that  from  a user  standpoint 
this  would  probably  be  thought  the  most  "user  friendly”, 
however,  it  should  be  pointed  out  that  once  a user  truly 
understands  what  is  required  he  might  very  likely  change  his 
mind  about  its  friendliness.  In  addition,  the  user  would  have 
to  interface  with  two  structured  organizations  that  in  general 

I 

are  most  concerned  with  getting  their  prime  job  of  running  a 
Space  Station  and  launching  space  vehicles  accomplished. 

In  terms  of  effectiveness  this  option  was  not  considered  very 
favorably.  The  transition  to  it  since  it  is  such  a major  change 
would  be  very  difficult.  It  would  require  each  user  to  have  or 
to  "buy”  the  skills  and  tools  to  perform  the  job.  This  would 
increase  cost  and  create  a potential  management  problem  for  the 
user.  Probably,  a number  of  iterations  would  be  required  of  the 
data  and  the  analyses  between  the  user  and  the  Space  Station  and 
STS  before  an  acceptable  product  was  obtained,  all  increasing 
cost  and  jeopardizing  performance  and  safety. 

This  option  was  rated  last  by  the  panel . The  major  point 
against  it  is  that  with  the  diverse  number  of  users  that  the 
Space  Station  will  encounter,  the  skills  and  capability  that  the 
users  will  possess  will  vary  so  much  that  it  would  not  be 
practical  to  expect  them  to  be  able  to  perform  all  the  analysis 
functions  and  for  each  to  obtain  the  capability  would  be  a major 
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duplication  of  efforts  with  associated  high  cost  and  management 
inefficiencies . 

Option  2.  Dser  Representative  I - The  simple  diagram  of  this 
option  is  shown  in  Figure  2-8.  As  noted,  the  prime  difference 
in  this  option  is  the  addition  of  the  Science  and  Technology 
(S&T)  Center.  In  this  case  the  user  would  interface  with  the 
appropriate  S&T  Center.  The  S&T  would  support  and  assist  the 
user  in  performing  and  documenting  the  required  analyses  and 
test  activities,  represent  the  user  to  the  Space  Station  and  STS 
at  major  reviews;  i.e.  safety,  flight  readiness,  etc.,  and 
perform  the  integrated  payload  analyses  in  their  discipline 
area.  The  Space  Station  and  STS  organizations  would  still  need 
to  perform  the  total  integrated  payload  analysis  for  their 
respective  systems.  For  users  not  represented  by  a particular 
S&T  Center,  they  would  interface  directly  with  the  Space  Station 
and  STS  organization  as  in  Option  1. 

Analysis  - This  option  was  definitely  judged  to  be  feasible, 
although  we  could  not  ascertain  how  many  S&T  Centers  may  come 
into  being  in  the  future.  S&T  Centers  would  provide  good 
flexibility  in  responding  to  changes  from  a scientific  viewpoint 
and  would  provide  a very  friendly  and  compatible  interface  to 
the  users,  since  they  all  work  in  the  same  basic  science  or 
technology  discipline.  For  the  Space  Station  and  NSTS  organiza- 
tions there  would  be  fewer  organizations  interfacing  with  them 
than  in  the  previous  option,  thus  allowing  them  to  assess  and 
respond  more  rapidly  to  resources  or  mission  changes. 

The  overall  effectiveness  of  this  option  was  rated  average.  The 
strengths  lay  in  the  management  organization  in  relation  to  the 
users,  the  knowledge  base  between  the  two  and  being  able  to 
focus  this  into  the  analyses,  and  work  relationships  and 
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FIGURE  2-8  USER  REPRESENTATIVE  I 
(S&T  CENTER) 
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interactions  with  the  Space  Station  and  NSTS  organizations. 
Duplication  o£  the  skills  and  tools  required  to  perform  the 
payload  analyses  activities  by  a number  of  organizations  and  the 
interfacing  of  these  various  S&T  Centers  to  the  Space  Station 
and  NSTS  would  not  be  the  most  cost  effective  or  obtain  optimum 
performance. 

This  option  rated  third  in  our  rankings , based  primarily  on  the 
duplication  of  analytical  resources  and  number  of  interfaces  to 
Space  Station  and  NSTS.  It  was  also  questioned  if  all  of  the 
proposed  S&T  Centers  would  possess  the  capabilities  for 
performing  the  analytical  job.  The  major  strength  of  this 
option  is  in  its  interface  and  relationship  to  the  users  from 
the  science  and  technical  discipline  aspects. 

Option  3.  User  Representative  II  - The  Option  3 top  level 
diagram  is  shown  in  Figure  2-9.  In  this  option  a Payload 
Integration  Organization  (PIO)  is  introduced.  All  users  would 
interface  to  the  PIO.  The  PIO  would  perform  functions  for  the 
users  and  the  program  such  as:  define  and  help  users  in 

performing  and  documenting  their  analyses  and  verification 
activities;  represent  and  respond  for  the  users  to  the  Space 
Station  and  NSTS  organizations;  perform  the  total  integrated 
analyses  and  verification  activities  for  the  mission  and  support 
the  on-orbit  mission  activities  as  required.  The  users  in  this 
option  would  have  a single  interface  to  work  with  that  would 
represent  them  to  the  Space  Station  and  NSTS  organizations. 

This  option  is  basically  the  same  as  the  Mission  Manager  concept 
utilized  by  the  MSFC  Spacelab  Payloads. 

Analysis  - This  option  essentially  represents  the  current 
functioning  of  the  MSFC  Spacelab  Payloads  Program.  Thus,  it  is 
definitely  feasible  and  well  understood  as  to  what  it  takes  to 
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FIGURE  2-9  USER  REPRESENTATIVE 
(PIO  INTERFACE) 
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make  it  work.  The  flexibility  of  this  option  in  responding  to 
program  changes  and  changes  of  payload  and  or  resources  is  very 
good  since  there  is  a focused  effort  in  assessments,  all  concen- 
trated by  a single  organization.  In  the  matter  of  user  friend- 
liness, this  option  was  rated  good.  The  user  would  only  have  to 
interface  with  one  point  of  contact  for  all  his  needs  and  the 
PIO  would  work  very  closely  and  perform  some  of  the  analyses  the 
user  would  normally  be  expected  to  perform. 

For  overall  effectiveness  this  option  was  rated  the  best.  It 
focuses  all  of  the  skills  and  analytical  tools  into  a single 
organization  that  performs  these  functions  repetitively,  thus 
deriving  increased  efficiency.  The  single  interface  to  the 
Space  Station  and  NSTS  allows  for  efficient  and  clear  under- 
standing of  requirements  and  their  implementation.  The 
management  structures  are  reduced  and  costs  for  the  users.  Space 
Station,  and  NSTS  should  be  minimized. 

This  option  was  rated  highest  by  the  panel . The  major  strengths 
were  the  consolidation  of  all  the  required  skills  and  tools  in  a 
single  organization  and  the  establishment  of  single  interfaces 
with  the  Space  Station  and  NSTS.  The  basic  weakness  is  the  user 
interface  area,  in  that  the  PIO  will  not  understand  or  be  as 
attuned  to  the  desires  and  needs  of  the  user  as  would  the  S&T 
organization. 

Option  4.  Combination  - This  option  is  shown  in  a diagram  form 
in  Figure  2-10.  This  option  is  a variation  on  the  previous 
options  and  takes  the  two  main  features  of  Options  2 and  3 and 
combines  them.  In  this  option  both  the  S&T  centers  and  the  PIO 
are  incorporated.  The  roles  of  each  of  these  organizations 
would  be  basically  as  described  under  the  appropriate  option 
previously.  The  major  difference  would  be  that  the  S&T 
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organization  would  only  interface  to  the  PIO  and  would  do  only  a 
limited  integrated  payload  function.  It's  prime  function  would 
be  to  support  and  act  as  a surrogate  for  its  class  of  discipline 
users.  The  PIO  functions  would  be  essentially  as  defined  in 
Option  3 except  it  would,  where  appropriate,  work  with  and 
through  the  S&T  Centers  for  those  users.  Again  users  not 
represented  by  an  S&T  Center  would  work  directly  with  the  PIO. 

Analysis  - The  combination  evaluated  for  this  option  was  one  of 
taking  the  S&T  Centers  of  Option  2 and  having  them  provide  an 
interface  function  in  Option  3.  In  particular  areas,  primarily 
Life  Sciences,  the  Spacelab  Payloads  are  integrated  in  this 
manner.  This  option  incorporates  the  best  features  of  the  two 
options  and  molds  them  into  a single  strong  one.  The  primary 
user  friendly  feature  and  strong  scientific,  technical  interac- 
tion of  the  S&T  organization  is  retained  while  the  consolidated, 
dedicated  PIO  with  its  unique  skills  and  tools  is  maintained. 

The  negatives  to  this  are  the  increase  in  the -overall  number  of 
interfaces  and  participating  organizations  with  their  attendant 
increase  in  cost. 

This  option  was  picked  second  in  our  evaluations.  The  strong 
points  is  the  utilization  of  two  organizations  with  their  own 
dedicated,  special  expertise  doing  what  they  can  do  best.  The 
negative  is,  in  the  overall  total  program  sense,  the  increase  in 
cost  due  to  the  two  organizations. 

Conclusion  and  Recommendations 

From  our  numerical  grading  system  Options  3 was  rated  highest. 
However,  during  our  discussions  we  came  to  the  conclusion  that 
the  preferred,  and  thus  our  recommended  option,  would  be 
Option  4.  This  recommendation  is  based  on  the  facts  as 
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presented  previously.  Namely,  that  the  utilization  of  the  S&T 
Centers  performing  a major  interface  and  support  service  for  the 
users  to  the  PIO  which  would  perform  the  integrated  payload 
analysis  activities  and  provide  the  interface  and  required 
support  to  the  Space  Station  and  NSTS.  This  structure  would 
provide  the  most  user  friendly  environment  and  would  be  the  best 
from  an  overall  management  viewpoint.  Each  participant  would 
have  well  defined  responsibilities  and  clear  and  simple 
interfaces.  Assuming,  as  seems  to  be  the  case,  that  the  science 
and  technical  disciplines  are  moving  toward  establishment  of  S&T 
Centers,  as  the  Life  Sciences  have  already  done,  then  these  S&T 
Centers  would  not  be  an  added  cost  factor  but  could  perform  a 
very  cost  effective  interfacing  function  in  the  Space  Station 
era.  The  optimum  utilization  of  the  S&T  Centers  in  combination 
with  the  PIO  is  the  recommended  approach  for  accomplishing  the 
payload  analysis  function  and  thus  providing  the  interface 
during  its  performance. 

SUPPORTING  DOCUMENTATION  FOR  ANALYSIS  - An  important  and 
necessary  aspect  of  the  payload  integration  process  for  the 
Space  Station  Program  will  be  the  documentation  required  to 
support  the  analytical,  integration  and  verification  efforts. 
Previous  experience  with  such  documentation  systems  was  for 
payloads  to  be  flown  on  the  NSTS,  on  Spacelab,  and  payloads 
launched  by  ELV's.  The  main  objective  of  any  document  system 
selected  for  the  Space  Station  Program  would  be  to  provide  the 
proper  information  for  payload  interfaces  with  the  STS  and  Space 
Station  and  to  identify  safety  issues  for  both  Space  Station  and 
STS  operations.  The  selected  system  should  provide  traceability 
of  payload  processing  operations  and  should  aid  in  anomaly 
resolution.  The  document  system  would  not  concern  itself  with 
payload  operations  other  than  interface  compatibility  and  safety 
implications  for  the  NSTS  and  Space  Station.  In  considering 
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various  options  for  documentation  systems  it  was  assumed  that 
there  will  be  a single  authority  source  for  all  safety  policies 
and  procedures. 

The  options  evaluated  are  as  follows: 

1 . Use  existing  NSTS  PIP  System  and  annexes  for  both  NSTS  and 
Space  Station  documentation. 

2.  Use  separate  documents  for  NSTS  and  Space  Station 

a.  NSTS  would  use  existing  system 

b.  Space  Station  would  use  separate  but  comparable  system 

3.  Use  a modified  NSTS  document  system  combined  with  Space 
Station  documentation. 

4.  Use  documentation  prepared  by  users  against  guidelines 
provided  by  the  Space  Station  program. 

In  addition , two  modes  of  processing  and  distributing  the 
documents  were  reviewed.  These  were  a paper  document  system, 
and  an  electronic  data  file  document  system. 

A major  concern  for  the  selected  option  is  that  it  allows  for  a 
single  NASA  interface  for  all  users  and  that  the  documentation 
be  as  simple  and  concise  as  possible.  The  documents  should  be 
tailored  to  the  class  of  users  (type,  size,  discipline)  and  be 
formatted  to  minimize  redundancy. 

Option  1 . Use  Existing  NSTS  PIP  System  and  Annexes  for  both 
NSTS  and  Space  Station  Documentation  - Use  Existing  NSTS  PIP 
System  and  This  option  consists  of  using  the  NSTS  Payload 
Integration  Plan  (PIP)  and  Annex  format  as  it  exists  and  folding 
in  the  requirements  for  Space  Station  program  interfaces  and 
safety  into  the  appropriate  PIP  sections  or  annexes.  The  NSTS 
PIP  defines  the  basic  and  optional  services  required  by  the 
payload  for  NSTS  flight  hardware,  ground  integration  facilities. 
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and  flight  payload  operations  control  center  and  its  interfaces 
with  the  mission  control  center.  The  PIP  describes  the  launch 
parameters  for  the  shuttle.  Thus  the  PIP  is  a document  system 
which  delineates  the  analytical  and  physical  integration, 
technical  activities,  interfaces,  and  schedules  for  payloads 
which  are  to  be  integrated,  launched  and  deployed/operated  on 
the  NSTS.  The  PIP  annexes  are  the  source  of  detailed  technical 
data  supporting  the  payload  integration  process  in  the  areas  of 
payload  data,  thermal  and  structural  loads  and  models,  flight 
planning,  flight  operations  support,  training  and  launch  site 
support  planning. 

The  objective  of  this  option  would  be  to  use  this  NSTS  PIP 
format  to  incorporate  the  interface  and  safety  requirements  of 
payloads  that  are  to  be  integrated  into  the  Space  Station.  The 
data  required  to  support  payload  integration  to  the  logistics 
carrier,  the  core  station  (lab  modules)  and  station  interface 
adapter  on  the  Space  Station  truss  would  be  formatted  to  fit 
into  the  PIP  annexes  as  they  are  now  structured.  Thus  there 
would  be  a blend  of  information  for  the  logistics  carrier  and 
payload  interfaces  with  the  NSTS  system  and  the  Space  Station 
systems . 

Analysis  - From  a feasibility  standpoint  this  option  would  be 
difficult  to  achieve,  even  though  NSTS  is  an  existing  system  and 
users  are  familiar  with  the  system.  It  is  felt  that  the  NSTS 
document  system  would  be  difficult  to  modify  and  to  integrate 
the  Space  Station  requirements  into  that  format.  The  Space 
Station  program  will  require  information  that  is  substantially 
different  from  NSTS  integration  information.  An  example  is 
verification  data  requirements.  A major  expansion  of  the  PIP 
and  annexes  would  be  needed  to  include  the  scope  of  the  Space 
Station  Program  safety  and  interface  requirements. 
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When  considering  user  friendliness.  Option  1,  having  one  docu- 
ment system  (versus  multiple  documents)  would  keep  user  inter- 
faces to  a minimum.  However,  based  on  past  experience  with  the 
NSTS  system,  there  are  concerns  with  the  friendliness  of  this 
system.  The  first  time  STS  user  has  had  difficulty  in  following 
the  document  format  and  requirements . Users  have  expressed 
dislike  for  the  system,  but  have  admitted  that  the  system  works. 
There  have  been  problems  between  the  requirements  for  the  PIP 
and  annexes  as  viewed  by  Johnson  Space  Center  and  the  ground 
operations  documents  that  are  required  by  Kennedy  Space  Center 
for  processing  payloads.  These  problems  result  in  redundancy 
and  confusion  about  ground  processing  requirements. 

In  the  area  of  management  effectiveness,  while  a single  NSTS 
type  document  system  would  allow  for  adequate  management 
controls  to  be  applied,  there  would  be  difficulty  in  assuring 
clearly  defined  responsibilities.  Change  control  for  the  NSTS 
and  Space  Station  systems  would  require  clear  definition  to 
assure  that  proper  controls  are  applied  to  NSTS  and  Space 
Station  separately. 

The  NSTS  document  system  as  it  now  exists  is  a relatively  high 
cost  system  to  maintain.  Modifying  this  system  to  incorporate 
the  Space  Station  Program  requirements  would  be  a costly 
process . 

Option  2.  Use  Separate  Documents  for  NSTS  and  Space  Station  - 
This  option  would  utilize  the  existing  NSTS  PIP  and  annex  system 
to  document  the  integration  of  the  Space  Station  logistics 
carriers  and  payloads  (those  that  do  not  utilize  the  logistics 
carrier  for  transport  to  the  station)  to  the  NSTS.  It  is 
expected  that  the  interfaces  between  the  Space  Station  logistics 
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carrier /pay loads  and  NSTS  System  will  be  kept  to  a minimum,  thus 
allowing  the  documentation  to  be  simplified. 

A separate  document  system  would  be  developed  to  cover  payload 
interfaces  and  safety  consideration  with  Space  Station  systems. 
Precedent  for  such  an  approach  can  be  found  in  the  Spacelab 
Program.  This  program  created  mission  requirement  for  payloads 
document  which  established  the  integration  and  safety  data 
required  for  payload's  interfacing  with  the  Spacelab.  The 
proposed  documentation  system  for  the  Space  Station  Program 
could  be  tailored  to  the  various  classes  of  payloads  and  would 
cover  the  interfaces  with  Space  Station  System  such  as  the  DMS, 
power,  thermal,  structure,  and  ELCSS.  In  addition,  verifi- 
cation, training,  safety  compliance,  payload  requirements,  mass 
properties,  data  flow,  flight  definition,  and  payload  operations 
would  be  documented. 

With  this  two  document  system  the  user  would  provide  information 
to  the  Space  Station  organization  responsible  for  the  Space 
Station  documents  and  this  organization  would  then  develop  the 
integration  data  needed  for  the  NSTS  PIP  document  system. 

Analysis  - The  use  of  separate  documents  has  precedence  in  the 
Spacelab  Program.  The  MSFC  has  created  a document  system  for 
users  that  fly  on  the  Spacelab.  The  NSTS  PIP  and  Annexes  are 
also  used  to  document  the  integration  of  the  Spacelab  into  the 
NSTS  as  a payload.  Thus  it  is  very  feasible  that  a two  document 
approach  could  be  achieved  for  the  Space  Station  Program. 

There  are  some  concerns  with  the  friendliness  of  a two  document 
system  to  the  user.  These  concerns  center  around  the  need  to 
maintain  a single  source/point  of  contact  for  the  users.  With  a 
two  document  system  there  is  a chance  for  redundancy  in 
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requirements  and  additional  interfaces.  However,  it  is  possible 
to  tailor  the  Space  Station  document  to  the  various  class  of 
users  and  assure  that  the  Space  Station  document  would  be  the 
single  point  of  contact  for  the  users.  The  Space  Station 
program  would  then  work  the  interfaces  required  with  the  NSTS 
PIP  and  annexes. 

Effective  management  would  be  achieved  even  though  there  would 
be  two  organizations  involved  in  document  preparation.  Based  on 
Spacelab  experience,  clear  responsibilities  and  document  scope 
could  be  established  and  management  control  over  these  areas 
could  be  put  into  effect. 

The  performance  effectiveness  of  a two  document  system  should  be 
reasonably  high  due  to  the  opportunity  to  streamline  and  tailor 
the  documents  to  the  Space  Station  Program  needs.  There  is  the 
potential  in  the  Space  Station  document  to  break  away  from  the 
constraints  and  framework  exhibited  by  the  NSTS  PIP  and  be  more 
innovative  in  formatting  the  Space  Station  document.  There  is 
concern  however,  that  with  a two  document  system  that  important 
data  or  requirements  will  be  overlooked  and  not  be  covered  in 
either  document. 

Initial  consideration  of  the  cost  of  a two  document  system  would 
indicate  potentially  higher  costs,  however,  with  the  opportunity 
to  tailor  the  Space  Station  document  (rather  than  force  fit  into 
the  STS  framework)  the  long-term  costs  should  prove  to  be  lower. 

Option  3.  Dse  a Modified  STS  Document  System  Combined  with 
Space  Station  Documentation  - Instead  of  using  the  NSTS  PIP  and 
annexes  as  they  are  now  formatted  this  option  would  seek  to 
modify  the  NSTS  system  to  accommodate  the  requirements  of  the 
Space  Station  program  and  provide  a singular  approach  to  Space 
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Station/NSTS  payload  integration.  The  NSTS  PIP  would  be 
modified  to  incorporate  the  basic  and  optional  services  required 
by  the  payload  for  Space  Station  systems  and  hardware,  ground 
integration  facilities  and  payload  operations  interfaces  with 
the  Space  Station  control  centers.  Included  in  the  PIP  would  be 
Space  Station  flight  core  systems  parameters.  This  combined 
document  would  delineate  technical  data  supporting  the  payload 
integration  process  for  the  STS  and  Space  Station  in  the  areas 
of  payload  date,  thermal  and  structural  loads  and  models,  flight 
operations  planning  and  support,  training  and  launch  site 
support  planning. 

Analysis  - This  option  is  essentially  a variation  of  option  1, 
which  is  an  attempt  to  use  the  existing  STS  document  system  as 
is,  with  Space  Station  requirements  folded  into  that  document 
system  framework.  For  this  option  the  NSTS  PIP  and  annex  format 
would  be  modified  to  directly  accommodate  the  requirements  of 
the  Space  Station  Program. 

While  such  a combined  document  might  provide  the  opportunity  for 
effective  management  control,  there  may  still  be  difficulty  in 
establishing  clear  lines  of  responsibility  between  the  NSTS  and 
Space  Station  Programs.  In  fact,  there  is  a strong  opinion  that 
the  NSTS  program  requires  a separate  system,  because  NSTS  will 
launch  payloads  other  than  the  Space  Station.  A separate 
system  may  also  be  necessary  because  of  the  scope  and  complexity 
of  both  the  STS  and  Space  Station  programs. 

The  attributes  identified  in  a one  document  system  (Option  1) 
are  applicable  to  this  option  with  the  added  possibility  that 
the  modification  of  the  NSTS  document  system  for  Space  Station 
requirements  could  incorporate  improvements  which  would  make  the 
system  more  user  friendly.  However,  these  improvements  would 
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not  be  without  impact,  since  the  existing  NSTS  user  community  is 
familiar  with  the  existing  system.  There  would  also  be  a cost 
impact  to  incorporate  modification  into  the  NSTS  document 
system. 

Option  4.  Ose  documentation  prepared  by  users  against 
guidelines  provided  by  the  Space  Station  Program  - In  the 
previously  discussed  three  options,  the  Space  Station  organiza- 
tion would  prepare  the  documentation  required  for  integration  of 
payloads  with  the  NSTS  and  Space  Station  systems  with  the  user 
providing  supporting  information.  This  option  would  seek  to 
establish  a guideline  format  that  would  allow  the  user  to 
prepare  the  necessary  documents  for  payload  integration.  The 
necessary  Space  Station  and  STS  background  and  guidance 
information  would  be  documented  to  allow  the  user  to  indepen- 
dently prepare  interface  and  safety  data.  The  Space  Station 
organization  responsible  for  interfacing  with  the  users  would 
serve  in  a review  capacity  to  assure  compliance  by  the  user 
with  the  Space  Station  Program  guidelines.  One  approach  to 
achieving  this  option  is  a "blank  book"  system  which  covers  all 
potential  areas  of  payload  integration  and  processing  documenta- 
tion required.  The  user  would  fill  in  information,  based  on  the 
results  of  analyses  performed,  in  the  appropriate  sections  of 
the  book  using  the  guidelines  provided. 

Analysis  - At  first  look  this  option  appears  to  very  user 
friendly,  since  the  user  would  deal  with  a standardized  system 
which  serves  as  a singular  interface.  However,  it  is  likely 
that  first  time  users  will  have  difficulty  interpreting  the 
guidelines  (difficult  to  make  complex  interfaces  standardized). 
Misinterpretations  would  require  users  to  redo  their  initial 
efforts  and  could  result  in  a frustrating  iterative  process. 
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This  option  may  prove  to  be  difficult  to  effectively  establish 
management  control. 

This  option  would  be  most  costly  to  the  user  since  he  would  be 
required  to  provide  most  of  the  document  preparation.  It  would 
also  be  costly  to  the  Space  Station  Program  to  maintain  the 
guideline  system  and  to  interact  with  the  user  in  iterative 
updates  of  the  document  inputs  to  achieve  proper  results. 

There  are  concerns  with  achieving  an  acceptable  performance 
level  with  a guideline  system.  Such  concerns  are:  more  poten- 

tial for  error  in  input;  highly  iterative  process;  and  proper 
analysis  reporting  for  safety  items  (users  often  are  not  as 
sensitive  to  safety  issues  as  NASA) . 

Document  Mode  - The  mode  or  media  to  be  used  in  preparing, 
distributing  or  transferring  the  required  Space  Station 
documents  was  reviewed.  Only  two  modes  were  considered:  the 

existing  paper  system  that  is  used  on  NSTS  and  Spacelab  programs 
and  the  concept  of  a paperless  document  mode. 

Analysis  - Using  a paper  document  system  similar  to  NSTS  result 
in  an  extensive  array  of  documents  due  to  the  complexity  and 
scope  of  the  Space  Station  Program.  Such  a large  system  will  be 
cumbersome  to  utilize  efficiently.  A paper  system  has  proven  to 
be  flexible  and  able  to  adjust  to  program  changes. 

Electronic  data  base  document  systems  are  currently  being 
established  in  the  Space  Station  Program  and  should  be  used  to 
the  greatest  extent  practical.  However,  limitations  of  handling 
data  bases  need  to  be  recognized.  Such  a system  needs  to  be 
structured  to  impose  safeguards  of  information  transfer  and  to 
establish  methods  to  simplify  the  management  of  complex  data 
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bases.  Electronic  data  bases  for  documents  should  prove  benefi- 
cial to  cross-checking  safety  requirements. 

Conclusions  and  Recommendations 

The  subjective  evaluation  of  the  options  against  the  various 
criteria  resulted  in  the  following:  Option  2 (separate  Documents) 
was  seen  as  the  most  feasible,  flexible,  and  management  effective 
option.  All  options  rated  about  the  same  on  cost  effectiveness 
and  safety.  Proper  documentation  is  a high,  but  necessary,  cost 
burden  and  concerns  were  identified  with  safety  reporting  for 
Option  4,  the  "guideline"  system.  Option  4 received  the  highest 
rating  for  user  friendliness,  but  with  the  caveat  that  it  may 
prove  to  be  a highly  iterative  process.  Option  4 also  achieved 
a'  high  rating  for  ease  of  proprietary  operations. 

Based  on  the  above  consideration.  Option  2r  separate  STS  and 
Space  Station  document  systems  was  seen  to  have  the  best 
attributes  and  achieved  high  ratings  in  the  key  areas  of  user 
friendliness,  cost  and  management.  The  key  features  of  Option  2 
are:  The  use  of  the  existing  separate  NSTS  system  which  the 

Space  Station  Program  could  readily  interface  with;  the  oppor- 
tunity to  tailor  the  Space  Station  Program  document  to  the 
various  user  classes;  and  the  chance  to  be  innovative  in  design- 
ing the  format  of  the  Space  Station  document  system  based  on 
lessons  learned  from  the  STS  and  Spacelab  programs.  An  approach 
to  the  Space  Station  Program  document  system  is  addressed  in  the 
paper  "An  Approach  to  Space  Station  Documentation"  in  Appendix  D. 

It  is  recommended  that  the  use  and  development  of  electronic 
data  bases  for  documents  be  expanded  as  practical  during  the 
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development  of  the  Space  Station  Program,  thus  reducing  reliance 
on  a paper  document  system. 

PHYSICAL  INTEGRATION/DEINTEGRATION 

Payload  and  Logistics  Module  Buildup  - Physical  integration,  in 
the  context  of  user  provided  flight  experiments /equipment  for 
Space  Station  application,  is  defined  as  an  early  activity  in 
overall  experiment  ground  processing  where  the  actual  flight 
experiment  hardware  transitions  from  a "stand  alone"  support 
structure  to  a flight  qualified  support  structure.  This 
hardware  combination  will  ultimately  be  functionally  operated  in 
the  micro-gravity  environment  of  Space  Station. 

Deintegration  is  the  post  flight  removal  of  experiment  hardware 
from  the  flight  support  element.  The  Space  Station  provided 
flight  support  element  is  configured  as  required  for  next  flight 
experiment  application.  User's  equipment  is  dispositioned  by 
the  user. 

Options  - The  discussion  of  options  considered  by  the  Subpanel 
focus  on  the  issue  of  physical  integration  occurring  only  at  the 
launch  site  (Option  1:  Centralized  Physical  Integration)  vs. 

physical  integration  also  occurring  at  other  locations 
(Option  2:  Decentralized  Physical  Integration).  Centralized 

experiment  integration  would  occur  exclusively  at  the  launch 
site  and  decentralized  integration  would  occur  at  locations  such 
as  Science  and  Technology  Centers  or  Commercial  R&D  Centers  as 
well  as  at  the  launch  site. 

Two  additional  options  were  included  to  treat  the  special  case 
for  the  location  of  experiment  to  Space  Station  final  interface 
validation.  These  options  are:  Option  3 - Decentralized 
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Physical  Integration  with  Final  Interface  Validation  at  Work 
Package  Center,  and  Option  4 - Decentralized  Physical  Integra- 
tion with  Final  Interface  Validation  at  the  launch  site. 

The  Subpanel  assessment  objective  was  to  identify  an  approach 
for  Space  Station  that  is  low  cost  and  gives  high  performance 
(utility)  while  being  "friendly"  to  the  user  community.  The 
"user-friendly"  factors  would  include  low  user  cost,  fast  and 
easy  on  and  off  of  Station,  and  minimum  travel  away  from  user's 
home  base.  The  intent  is  to  structure  Space  Station  facilities, 
equipments,  and  operations  such  that  user's  would  have  a wide 
envelope  to  operate  within  and  still  meet  minimum  Space  Station 
requirements . 

International  Partner  Planning  - The  Operations  Task  Force 
hosted  the  International  Partners  in  a review  of  planning  for 
the  mature  operations  phase  of  Station.  ESA  and  NASDA  represen- 
tatives both  indicated  plans  for  a decentralized  approach  to 
experiment  physical  integration.  The  significant  aspects  of 
their  planning  are:  (1)  distributed  user  facilities  for 

physical  integration  and,  (2)  final  experiment /support  element 
to  Space  Station  interface  validation  at  the  launch  site  in  the 
event  of  shipping  damage  or  other  need  for  experiment  interface 
verifications . 

Assumptions  - A baseline  assumption  is  that  the  flight  qualified 
support  elements  will  be  provided  by  the  Space  Station  Program. 
Space  Station  provisions  with  these  support  elements  will 
include  at  minimum  the  physical  structure  and  mechanical  attach 
points  and  may  optionally  include  select  devices  and/or  inter- 
faces for  services,  such  as,  electrical  power,  avionics  cooling, 
command  and  data,  etc. 


2-76 


The  physical  integration  into  the  flight  support  element  occurs 
only  after  the  experiment  hardware  or  instrument  package  is 
mature  in  design  and  development.  Activity  in  proximity  of  the 
flight  support  element  shall  not  be  harmful  to  engineering 
integrity  or  flight  worthiness  of  Space  Station  provided 
components . 

Following  physical  integration  the  essential  subsequent  steps  to 
launch  readiness  are  (1)  experiment  functional  verification  in 
the  flight  support  element,  (2)  experiment  to  Space  Station 
interface  validation,  (3)  experiment  prelaunch  servicing,  and 
(4)  launch  package  integration.  These  sequential  steps  are 
illustrated  in  the  flow  chart  of  Figure  2-11. 

PAYLOAD  HARDWARE /SOFTWARE  BUILDUP 

Option  1.  Centralized  Physical  Integration  Site  - This  option 
focuses  on  a centralized  capability  located  at  the  launch  site 
for  physical  integration  of  payloads /experiments  into  Space 
Station  user  flight  support  elements,  such  as,  module  racks, 
attached  payloads  interface  adapters,  f reef Iyer  carriers,  and 
platforms.  The  concept  is  that  followed  during  Spacelab.  The 
Space  Station  Program  would  acquire  the  minimum  necessary  set  of 
payload  support  elements  in  the  baseline  program  for  user 
accommodations.  This  basic  set  would  be  sized  to  satisfy  the 
on-orbit  complement  as  well  as  the  minimum  necessary  set  in  the 
overall  supply  and  return  "pipeline"  that  accommodates  support 
element  integration  through  launch  and  subsequent  return  to 
operational  inventory  after  landing.  The  quantity  sizing  of 
this  operational  flight  inventory  is  based  solely  on  total 
launch  site  integration  with  all  flight  element  hardware 
retained  at  KSC.  Instrument /experiment  breadboarding  and  devel- 
opment at  the  development  centers  include  physical  integration 
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into  high  fidelity  ground  equivalent  support  elements  or  design 
to  flight  rack  Interface  Control  Documents  (ICD's).  Following 
delivery  of  the  experiment  to  the  launch  site  and  post  delivery 
inspections,  the  experiment  is  installed  into  the  flight  support 
element  which  has  already  been  configured  and  certified  in  the 
centralized  facility.  Launch  site  personnel  would  perform  the 
installation  function  for  all  items  entering  a rack  whether 
representative  of  one  or  multiple  experiments.  The  combined 
integrated  experiment  and  support  element  would  then  undergo 
final  Station  interface  confidence  checks  with  a high  fidelity 
electrical,  electronic,  and  mechanical  simulator.  Following 
these  confidence  checks,  the  integrated  support  element  would  be 
placed  in  the  appropriate  launch  package  carrier  for  subsequent 
Orbiter  installation  and  launch  to  Station. 

Following  post  mission  return  to  the  launch  site  of  the  inte- 
grated experiment  support  element,  the  experiment  is  physically 
returned  to  the  user  provided  support  element.  The  flight  sup- 
port element  undergoes  centralized  inspection  and  recertifica- 
tion and  is  immediately  returned  to  the  centralized  operational 
inventory  for  next  mission  manifesting. 

Analysis  - This  approach  is  feasible  based  on  the  existing 
Spacelab  program  model.  Flexibility  in  capability  to  respond  to 
new  situations,  such  as,  late  changes  in  equipment  design,  late 
procedures  updates,  materials  changes,  etc.,  is  rated  acceptable 
from  users  viewpoint  and  the  Spacelab  experience  shows  the  Space 
Station  launch  site  centralized  approach  is  tolerant  to  new 
situations.  User  friendliness  was  viewed  only  as  acceptable. 
Oser  concern  stems  from  Spacelab  program  experience  in  which  the 
experiment  developer  was  not  a part  of  integrating  his  flight 
hardware,  even  though  he  retained  the  engineering  expertise  for 
the  hardware  and  the  experimenter  was  required  to  provide 
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temporary  duty  support  for  extended  periods  to  accommodate  the 
work  schedule  of  KSC  operations.  Ability  to  transition  from  C/D 
to  E in  this  option  was  rated  as  excellent  in  view  of  launch 
site  accommodations  for  rack  handling  and  flight  interface 
compatibility  checks  by  ground  simulators. 

Management  was  rated  with  desirable  features  in  view  of  s ( 1 ) 
defined  organizational  interfaces,  (2)  adaptable  evolving  roles 
and  responsibilities  during  successive  phases  of  ground 
processing  with  accountability  for  those  evolving  roles,  (4) 
clear  accountability  for  actions  taken.  In  assessing  this 
option  for  Station,  the  experience  base  of  the  Subpanel  members 
draws  largely  from  the  Spacelab  program.  In  the  Option  1 cost 
model,  the  user  costs  may  be  interpreted  to  be  minimized  by 
prudent  scheduling  of  user  arrival  at  the  central  integration 
launch  site  avoiding  any  unnecessary  dwell  time  and  allowing  the 
central  integration  personnel  to  have  fully  arranged  facility 
and  equipment  accommodations.  Congestion  is  avoided  by  sizing 
the  central  facility  for  optimum  Station  capability  considering 
its  maximum  capacity  on  orbit  and  the  logistics  resupply  system 
capacity  for  experiment  change-out.  Positive  cost  considera- 
tions assume  that  the  use  of  "telescience"  will  hopefully 
improve  the  Space  Station  cost  model  over  the  historic  Spacelab 
cost  model  in  that  less  user  equipment  and  fewer  user  support 
personnel  may  be  required  at  the  integration  and  launch  site. 
Because  of  available  interfaces,  performance  in  this  option  is 
expected  to  be  excellent.  The  required  functions  are  capable  of 
being  performed  in  the  "centralized  at  launch  site"  approach  and 
there  is  a high  potential  of  success.  The  major  detractants  of 
the  option  are  user  unfriendliness  and  cost  to  the  user  for 
personnel  temporary  duty  and  extended  schedules. 
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The  safety  aspects  of  this  option  were  assessed  highest  of  all 
options.  Key  features  included  launch  site  configuration 
control  of  flight  hardware,  quality  in  maintenance  and  servicing 
of  equipment,  and  reliable  and  most  current  launch  site  approved 
operations  and  test  procedures.  Proprietary  operations  consid- 
erations were  not  a discriminator  in  any  of  the  options  as- 
sessed. It  is  generally  believed  proper  controls  and  facility 
accommodations  will  be  available  to  meet  user  needs. 

Option  2.  Decentralized  Physical  Integration  - Decentralized 
integration  is  defined  as  payload  buildup  away  from  the  launch 
site.  This  option  would  make  Space  Station  racks.  Payload 
Interface  Adaptors  (PIA),  interface  simulators,  and  attached 
payload  elements  available  to  the  S&T  Centers  and  other 
organizations  which  act  as  experiment  development  centers 
representing  user  disciplines. 

S&T  Centers  have  provided  flight  hardware  to  Spacelab  and  will 
be  providing  flight  hardware  to  Space  Station  which  will  be  far 
complex  than  the  flight  racks  holding  that  hardware.  These 
Centers  currently  do  not  allow  Spacelab  hardware  procurement 
without  Defense  Contract  Administrative  Services  (DCAS)  or  "in 
place"  Quality  Assurance  (QA)  programs  at  manufacturing  vendors. 
They  have  provided  hardware  verification  plans  which  fulfilled 
Spacelab  Payload  Mission  Manager  Verification  Requirements  for 
Instruments,  Facilities,  MPE,  and  ECE,  JA061  requirements  and 
both  Flight  and  Ground  Safety  Plans  for  all  payload  elements  for 
which  they  have  had  responsibility.  They  maintain  both  hardware 
and  experiment  configuration  control  and  only  perform  testing  of 
flight  hardware  under  controlled,  approved  procedures  under  QA 
surveillance.  They  develop  and  deliver  flight  hardware  to  NASA 
program  standards  on  their  own  responsibility. 
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Timely  delivery  of  Space  Station  experiment  hardware  to  the 
launch  site  is  essential  to  support  short  term  LM  turnaround. 
Minimizing  hardware  handling  can  facilitate  such  delivery. 
Providing  racks  to  the  S&T  Centers  can  speed  up  the  turnaround 
process  for  hardware  resupply  from  several  aspects.  Awareness 
of  all  flight  rack  or  other  mounting  elements  interfaces  is  best 
accomplished  by  providing  the  rack  at  the  hardware  buildup  site. 
Allowing  the  user  to  perform  fit  and  function  of  hardware  in  a 
"near"  flight  configuration  prior  to  delivery  for  launch,  is 
essential  to  understanding  on  orbit  operations  and  will  facili- 
tate rapid  turnaround  when  finally  arriving  at  the  launch  site. 
Should  anomalies  occur,  the  Centers  have  the  engineering  exper- 
tise (womb  to  flight  history)  and  the  materials  to  correct  any 
problems  prior  to  delivery  of  the  hardware.  Resolution  of  field 
problems  on  temporary  duty  is  costly  to  the  user  in  terms  of 
personnel  support  and  shipments  of  material . Temporary  duty 
support  during  the  integration  of  experiment  hardware  into 
flight  racks  at  the  launch  site  proved  to  be  extremely  costly  to 
the  Development  Centers  (S&T)  during  the  Spacelab  era. 

Integration  to  the  rack  level  and  to  rack  interfaces  allows  easy 
and  speedy  transition  (as  required  for  final  checkout)  to  either 
the  Work  Package  (WP),  launch  site,  or  directly  into  Space 
Station. 

Analysis  - The  assessment  of  this  option  was  rated  highest  by 
the  panel.  The  primary  contributors  to  this  assessment  were 
flexibility  and  user  friendliness.  User  rating  also  accounted 
for  long  term  costs  to  the  user.  It  was  acknowledged  that 
decentralized  integration  would  necessitate  increased  cost  to 
the  Space  Station  Program  in  terms  of  additional  rack  sets, 
simulators,  other  interface  elements.  It  was  also  recognized 
that  these  were  upfront  costs  which  would  be  negligible  in  the 
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long  term  operational  costs  with  respect  to  fidelity  of  building 
hardware  to  Space  Station  interfaces,  timeliness  of  providing 
flight  hardware  to  the  launch  site,  and  user  costs.  Since  the 
developer  (S&T  Center)  encompasses  the  engineering  expertise 
pool , performance  and  safety  were  rated  as  equal  to  superior 
over  what  could  be  accomplished  at  the  launch  site.  In  fact, 
the  strong  identity  for  unimpaired  performance  is  more  inherent 
at  the  Development  Center,  whose  activities  must  result  in 
functioning  equipment  in  0-g. 

Internationals  have  indicated  that  they  are  distributing  their 
racks  for  their  respective  modules  to  their  users  for  rack 
integration  and  interface  testing,  with  final  interface  to  an 
engineering  verification  module  at  their  prime  integration 
center.  Decentralization  allows  the  International  developers  to 
retain  control  of  the  specific  rack  in  which  they  are  operating 
but  allows  the  flexibility  of  providing  International  racks  to 
U.S.  users  as  the  occasion  demands.  - The  same  mode  of  operation 
should  be  incorporated  in  the  U.S.  activities  for  both  near  and 
long  term  operations. 

Option  3.  Decentralized  Physical  Integration  with  Final 
Interface  Validation  at  Work  Package  Center  - In  this  option, 
the  interface  and  compatibility  testing  of  the  payload  element 
to  the  Space  Station  interface  test  device  (simulator)  after 
they  have  been  physically  integrated  into  and/or  on  the  Space 
Station  support  elements  would  be  performed  at  the  appropriate 
Work  Package  (WP)  element  site.  In  this  context,  the  Space 
Station  support  elements  are  defined  as  racks,  payload  interface 
adapters  (PIA),  and  platforms  and  the  WP  site  would  be  those 
that  support  WP  1 and  WP  3.  The  distinction  between  this  option 
and  option  4 is  the  location  of  the  payload  to  Space  Station 
interface/compatibility  test  activities. 
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The  flow  of  hardware  under  this  option  would  be  quite  diverse. 
Space  Station  racks  and  PIA's  would  be  provided  to  S&T  Centers, 
if  desired,  for  them  to  physically  integrate  the  payload  hard- 
ware. Space  Station  certified,  simplified  (suitcase  type)  Data 
Management  System  ( DMS ) simulators  would  be  provided  if  request- 
ed that  would  allow  the  S&T  Centers  to  do  a limited  interface 
verification.  For  those  users  not  represented  by  an  S&T  Center, 
or  who  so  desired,  would  have  their  payload  hardware  physical 
integration  performed  at  the  WP  site*  Subsequent  to  the  payload 
physical  integration  and  interface  testings  at  the  S&T  and/or  WP 
site,  the  total  mission  payload  complement  would  be  assembled  at 
the  WP  site  to  be  mated  with  the  appropriate  Space  Station  high 
fidelity  simulator.  During  this  test  setup,  the  payload  hard- 
ware to  Space  Station  hardware  interfaces  and  compatibility 
would  be  verified.  Following  this  test  activity,  the  payload 
complement  will  be  delivered  to  the  launch  site  for  installation 
and  verification  with  the  Space  Station  carrier;  e.g*,  LM  and 
finally  to  the  STS. 

This  option  would  define  two  WP  sites  to  which  payload  hardware 
would  flow  for  the  testing  functions.  The  WP  1 site  would 
receive  all  payloads  that  would  operate  in  the  internal  module; 
i.e.,  LAB  module,  and  would  maintain  and  operate  the 
high-fidelity  LAB  module  simulator  required  for  the  test  activi- 
ties. The  WP  3 site  would  perform  the  same  functions  for  all 
Space  Station  attached  payloads  and  for  platform  payloads.  The 
international  partners  would  maintain  and  operate  high  fidelity 
simulators  and  perform  the  same  functions  in  relation  to  ele- 
ments of  the  Space  Station  they  provided. 

Analysis  - The  assessment  of  this  option  by  the  Subpanel  was 
very  favorable.  The  feasibility  of  this  option  would  be  well 
established  since  its  approach  is  the  basic  planning  for  phase 
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C/D  period.  The  transition  to  it  in  the  operational  phase  would 
entail  minimal  disruptions  to  the  ongoing  program.  The  flexi- 
bility of  this  approach  to  respond  and  react  to  changes  is 
enhanced  compared  to  the  other  option.  This  is  based  on  two 
essential  facts:  (1)  the  decentralization  of  all  the  activities 

away  from  one  site  which  will  provide  a smaller,  less  structured 
organization  which  will  be  able  to  react  more  effectively  and 
also  less  likely  to  become  a "bottle  neck"  due  to  overload;  (2) 
the  centralization  at  one  site  of  the  processing  for  a 
particular  class  of  payload,  which  allows  the  organization  and 
people  to  become  specialist  and  efficient  in  doing  their  job; 
i.e.,  they  do  not  have  to  know  and  be  able  to  do  everything. 

The  same  factors  listed  above  also  enhances  the  user  friendly 
aspects  of  this  option.  In  addition,  the  option  allows  for  the 
user  to  "stuff”  racks,  perform  the  level  of  testing  he  can  do 
before  getting  in  the  big  system.  The  users  interfaces  to  the 
WP  element  site  would  be  only  required  to  define  and  implement 
the  integrated  test  activities  which  would  be  very  clear, 
straight  forward,  and  provide  the  maximum  autonomy  for  the  user. 

The  overall  effectiveness  of  this  option  was  rated  excellent. 

The  management  structure  required  for  this  option  would  be 
relatively  simple  since  its  sole  function  is  to  coordinate,  if 
done  by  the  user,  and/or  perform  physical  integration  and 
integrated  test  activities  on  a class  of  payload  hardware.  The 
roles  and  interfaces  of  the  participants  would  be  clearly 
defined,  thus  allowing  for  a high  degree  of  accountability  with 
well  defined  decision  points.  The  costs  for  implementing  this 
option  would  most  likely  be  higher  than  for  the  other  option. 
This,  in  large  part,  would  be  due  to  maintaining  two  sites  and 
organizations  for  doing  the  integrated  test  activities  instead 
of  just  one.  One  consideration,  which  could  reduce  the  cost  if 
it  could  be  accomplished,  would  be  the  use  of  the  high  fidelity 
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simulators  at  the  HP  1 and  HP  3 site  to  support  the  sustaining 
engineering  and/or  new  development/enhancement  function.  This 
would  allow  a cost  sharing  of  the  maintenance  and  operation  of 
these  simulators.  Whether  this  is  possible  or  not  will  be 
determined  by  the  schedules  and  workloads  of  each  of  the  two 
competing  users  of  the  simulators.  A much  more  detailed  study 
would  be  required  to  answer  these  questions.  Another  adverse 
cost  factor  for  this  operation  is  the  transportation  cost 
entailed  in  shipping  the  payload  elements  from  the  WP  1 or  WP  3 
test  site  to  the  launch  site. 

Performance  under  this  option  should  be  superior  because  it 
permits  apportioning  out  the  functions  to  where  they  can  best  be 
performed  based  on  the  skill  levels  and  expertise  required.  It 
allows  for  letting  the  users  do  the  physical  integration  and 
initial  interface  testing  where  the  expertise  on  the  payload 
hardware  resides  or  conversely  the  WP  site  where  the  detailed 
knowledge  of  the  Space  Station  hardware  exists.  The  integrated 
test  activities  are  performed  at  the  site  where  the  Space 
Station  hardware  expertise  exists  with  the  payload  users  tied  in 
via  the  telescience  network  or  on  site  as  the  case  may  be. 

Final  Space  Station  carrier  integration  and  STS  integration  is 
performed  at  the  launch  site  where  that  expertise  resides.  This 
mix  seems  to  utilize  and  optimize  the  knowledge  bases  available 
to  the  maximum  extent  possible.  Very  little  or  no  training  or 
transfer  of  knowledge  would  be  required  from  one  participant  to 
the  other  in  this  option.  The  mixes  of  the  functions  to  the 
appropriate  skills  sources  will  also  reduce  the  risks  involved 
in  regard  to  performance  and  schedule  and  enhance  the  safety 
aspects  of  the  program. 

Option  4.  Decentralized  Physical  Integration  with  Final 
Interface  Validation  at  Launch  Site  - This  option  provides 
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decentralized  locations  for  experiment  physical  integration 
in/on  flight  qualified  support  elements  (as  scoped  in  Option  2 - 
Decentralized  Physical  Integration)  and  adds  the  feature  of 
final  experiment  to  Space  Station  interface  validation  at  the 
launch  site* 

The  additional  feature  of  this  option  is  the  planning  to  use  the 
launch  site  Space  Station  simulation  capability  to  perform 
integrated  experiment  final  interface  functional  confidence 
checks  prior  to  launch  package  integration  and  installation  into 
the  Orbiter.  Users  have  indicated  the  need  to  provide  this 
interface  test  capability  at  the  launch  site.  This  must  be 
maintained  to  accommodate  unforseen  mishaps,  i.e.,  damage  to 
equipment  in  shipping  transit  from  the  S&T  facility.  The  Space 
Station  simulator  located  at  the  launch  site  will  have  been 
utilized  during  the  assembly  sequence  build  up  phase  and  would 
continue  to  function  during  the  mature  operations  phase.  The 
integrated  experiment  will  arrive  at  the  launch  site  and  be 
removed  from  its  transportation  equipment  in  the  SSPF  receiving 
area.  Following  visual  inspections,  the  experiment  package 
would  be  placed  in  the  appropriate  Space  Station  simulator 
device  and  functional  interfaces  would  be  verified.  After 
completion  of  necessary  checks,  the  experiment  would  be  removed 
from  the  simulator  and  installed  in  the  appropriate  logistics 
carrier  for  launch  package  integration. 

Upon  completion  of  the  mission,  the  experiment  is  returned  to 
the  SSPF  where  it  will  be  removed  from  the  logistics  carrier  and 
then  shipped  back  to  the  development  center. 

Analysis  - This  option  in  the  mature  Space  Station  operations 
phase  is  rated  favorably  overall  by  the  Subpanel.  The  approach 
of  final  interface  verifications  occurring  at  the  launch  site  is 
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considered  feasible  due  to  the  continued  use  of  Space  Station 
simulators  that  are  baselined  at  the  launch  site  for  the 
assembly  sequence  phase  of  Space  Station.  User's  have 
identified  the  requirement  to  make  final  checks  at  the  launch 
site  in  the  event  of  late  changes,  damage  resulting  from 
shipping,  or  resolution  of  technical  problems  discovered  during 
pre-launch  experiment  servicing  and  ground  processing.  With  the 
simulation  and  lab  capability  in  the  SSPF,  this  approach  is 
rated  excellant  in  flexibility  to  respond  to  new  situations. 

User  friendliness  is  rated  excellant  due  to  the  large  degree  of 
autonomy  afforded  with  S&T  Center  experiment  development  and 
physical  integration  but  reliability  of  operation  on  orbit  is 
significantly  enhanced  due  to  final  checks  made  at  the  launch 
site.  Ability  to  manage  this  option  is  assessed  as  excellant 
due  to  the  ability  to  clearly  identify  technical  and 
programmatic  interfaces  and  accountability  of  operations  at  the 
S&T  or  launch  site.  In  view  of  the  current  Space  Station 
approach  to  launch  site  facilities,  equipment  and  operations, 
the  transition  from  Phase  C/D  to  mature  operations  was  rated  by 
the  Subpanel  as  excellent. 

Safety  is  rated  as  low  risk  and  receives  an  excellent  rating. 
Proprietary  operations  considerations  were  not  a discriminator 
in  any  of  the  options.  Proper  controls  and  facility  accommoda- 
tions will  be  available  to  meet  user  needs. 

Conclusions  and  Recommendations 

Option  4,  Decentralized  Physical  Integration  with  Final  Inter- 
face Validation  at  the  Launch  Site,  was  selected  by  the  Subpanel 
as  the  preferred  option.  Information  presented  and  analysis 
considered  by  the  Subpanel  indicated  this  approach  was  best 
overall  for  achieving  Space  Station  Program  objectives  of  cost 
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effectiveness,  high  utility  to  Government  and  commercial  users, 
and  accommodation  of  International  Partner  planning.  The 
significant  cost  considerations  include  cost  avoidance  for 
manpower  and  travel  expenses  for  launch  site  physical  integra- 
tion as  well  as  lower  costs  associated  with  early  problem 
resolution  at  the  user's  development  facility.  Final  experiment 
to  Station  interface  validation  at  the  launch  site  assures  on 
orbit  compatibility  of  experiment  with  Space  Station  systems  and 
services. 


The  significant  features  of  the  recommended  approach  include 
provisions,  such  as,  (1)  shipping  of  flight  support  elements 
(racks,  PIA's)  to  user  facilities,  (2)  physical  integration  of 
experiments  and  their  functional  verification  by  the  development 
team  at  the  user's  facility,  (3)  use  of  selected  simulation 
devices  at  the  user  facility  for  interface  functional  checks, 

(4)  provision  at  the  launch  of  a master  interface  facility  for 
final  experiment  to  Space  Station  systems  interface  validation, 

(5)  SSPF  space  accommodations  for  any  required  experiment  post 
delivery  repairs  or  late  incorporation  of  minor  modifications, 

(6)  SSPF  accommodations  for  experiment  physical  integration  for 
experiments  suited  for  launch  site  integration. 


The  recommendation  of  the  Subpanel  is  for  adoption  of  Option  4, 
Decentralized  Physical  Integration  with  Final  Interface  Valida- 
tion at  Launch  Site.  Planning  towards  this  approach  should  be 
initialed  with  Phase  C/D  activity  to  assure  best  economies  early 
and  to  avoid  possible  future  organizational  or  systems 
restructuring . 


LOGISTICS  MODULE  BUILDUP  LOCATION 

Logistics  elements  include  NASA  and  international  partners 
proposed  elements.  The  international  partner  elements,  if 
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launched  in  the  U.S.,  would  follow  the  same  processing  flow  as 
the  NASA  element  with  responsibilities  and  performance  being  in 
accordance  with  international  agreement. 

The  logistics  module,  unpressurized  (dry)  carrier,  propellant 
carrier,  and  fluids  and  gases  carriers  make  up  the  NASA  ele- 
ments. The  logistics  module,  which  provides  pressurized  volume, 
is  the  primary  vehicle  for  uplifting  and  downlifting  (returning) 
both  Space  Station  and  payloads  items. 

The  dry  carrier,  propellants  carrier,  and  fluids  and  gases 
carriers  are  special  purpose  carriers.  Processing  flow  of  these 
carriers  will  be  as  required  by  the  logistics  resupply  of  Space 
Station  systems.  Payload  users  items  to  fly  on  these  carriers 
would  be  recognized  as  part  of  the  overall  requirement  and 
integrated  into  normal  flow. 

Two  options  for  location  of  logistics  module  operations  were 
evaluated.  One  option,  any  site  other  than  launch  site,  would 
cover  all  locations  away  from  launch  area.  Performance  of 
logistics  module  operations  at  the  launch  site  is  the  second 
option.  Installation  of  the  logistics  module  into  the  transport 
vehicle  (orbiter)  and  prelaunch/ launch  logistics  module  test 
team  participation  at  the  launch  site  is  common  to  both  options. 

Option  1.  Logistics  Module  Processing  at  Site  Other  than 
Launch  Site  - The  following  are  major  flow  operations  required 
for  Option  1: 

1.  Receiving  inspection  and  handling  operations  required  to 
process  the  logistics  module  shipped  from  post-flight 
deintegration  area. 
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2.  Inspection  for  visual  problems  and  of  areas  required  by 
design  element  in  requirements  and  criteria  (OMRSD) . 

3.  Returned  configuration  verification  to  module  replacement 
unit  level  such  as  stowage  lockers  is  accomplished  before 
module  deintegration.  Inventory  within  stowage  lockers  will 
be  accomplished  later  in  an  offline  location. 

4.  Deintegration  and/or  removal  of  those  items  not  planned  for 
reflight  and  those  items  which  require  some  operation 
outside  of  logistics  module. 

5.  Post-flight  verification  test. 

6.  Repair  and  maintenance. 

7.  Incorporation  of  design  changes  (modification  kits). 

8.  Installation  of  module  LRU's  required  by  next  flight 
configuration . 

9.  Installation  of  payload  users  items  (see  rack  options  for 
flow  description  of  user  items). 

10.  Test  of  module  system.  Interface  check  to  payload  user 
items  where  required. 

11.  Recertification  of  flight  condition  of  module  systems  per 
system  provided  requirements  and  criteria  (OMRSD).  This 
would  include  any  new  requirements  resulting  from  ground  and 
flight  problems,  trend  analysis,  life  cycle  requirements; 
etc.,  as  designated  and  required  by  sustaining  engineering. 


Analysis  - It  is  feasible  to  prepare  the  module  off-site, 
however,  additional  transportation,  handling,  and  shipping  would 
be  required.  The  processing  flow  time  would  be  increased 
thereby  reducing  flexibility  to  meet  schedule. 


Processing  the  module  at  a site  other  than  the  launch  site  would 
reduce  some  of  the  rigors  associated  with  processing  in  a launch 
environment,  such  as:  schedule  pressures;  get  ready  to  launch 
pressures;  and  use  of  shop  planning  documentation  as  opposed  to 
formal  launch  area  documents. 
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Processing  at  an  element  provider  site  would  provide  the  mecha- 
nism for  keeping  designer  expertise  onboard,  and  would  provide 
the  second  set  of  eyes  for  reliability,  quality,  problem  perfor- 
mance, safety,  and  life  considerations. 

Payload  user  elements  to  NASA  interfaces  would  be  increased. 

The  cost  of  maintaining  logistics  module  processing  capabilities 
at  both  sites,  which  would  be  required  for  final  verification 
and  installation  into  Orbiter  and  at  the  module  processing  area, 
would  be  greater. 

The  transition  from  the  development  phase  to  mature  operations; 
Space  Station  Program  management;  safety;  and  ease  of  proprie- 
tary operations  would  be  impacted  to  some  lesser  degree  by 
offsite  processing. 

The  ability  of  the  Space  Station  Program  to  make  major  evolu- 
tionary program  changes  to  incorporate  research  and  development 
and  new  technology  would  be  enhanced  by  processing  at  an  offsite 
element  (logistics  module)  provider  location. 

Option  2.  Performance  of  Logistics  Module  Processing  at 
Launch  Site  - The  following  are  major  flow  operations  required 
for  Option  2 : 

1.  Handling  of  logistics  module  within  local  processing 

facility  after  removal  from  Orbiter.  Note:  No  shipment. 

2.  Inspection  for  visual  problems  and  of  areas  required  by 
design  element  in  requirements  and  criteria  (OMRSD). 

3.  Returned  configuration  verification  to  module  replacement 
unit  level  such  as  stowage  lockers  is  accomplished  before 
module  deintegration.  Inventory  within  stowage  lockers  will 
be  accomplished  later  in  an  offline  location. 
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. Deintegration  and/or  removal  of  those  items  not  planned  for 
preflight  and  those  which  require  some  operation  outside  of 
logistics  module. 

5.  Post-flight  verification  test. 

6.  Repair  and  maintenance. 

7.  Incorporation  of  design  changes  (modification  kits). 

8.  Installation  of  module  LRU's  required  by  next  flight 
configuration . 

9.  Installation  of  payload  users  items  (see  rack  options  for 
flow  description  of  user  items). 

10.  Test  of  module  system.  Interface  check  to  payload  user 
items  where  required. 

11.  Recertification  of  flight  condition  of  module  systems  per 
system  provided  requirements  and  criteria  (OMRSD) . This 
would  include  any  new  requirements  resulting  from  ground  and 
flight  problems,  trend  analyses,  life  cycle  requirements; 
etc.,  as  designated  and  required  by  sustaining  engineering. 

Analysis  - Utilizing  the  launch  site  processing  location  reduces 

the  number  of  handling  and  shipping  operations. 


Processing  time  is  reduced  by  the  amount  of  time  which  would  be 
required  for  additional  shipping  and  handling  operations. 

Documentation  at  launch  site  would  follow  a more  formal  flow  and 
therefore  is  less  flexible  with  respect  to  changes.  A "get 
ready  to  launch"  environment  exists  and  puts  pressure  on  person- 
nel processing  hardware  to  meet  launch  goals. 


The  second  set  of  eyes  of  quality,  reliability,  and  design  and 
development  personnel,  which  is  inherent  in  using  site  where 
item  is  built  as  opposed  to  operations  personnel,  is  lost. 


The  number  of  NASA  interfaces  to  LM  users  is  reduced. 
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The  number  of  logistics  modules  required  to  meet  the  processing 
flow  is  minimized  because  the  need  to  provide  for  additional 
shipping  and  handling  time  involved  with  a remote  site  is  not 
necessary. 

The  transition  from  the  development  flight  phase;  Space  Station 
Program  Management;  and  the  ease  of  proprietary  operations 
would,  for  long  range  operational  life,  be  enhanced  by  process- 
ing at  the  launch  site  only,  as  opposed  to  multiple  sites 
processing. 

Conclusions  and  Recommendations 

Logistics  Module  Processing  - Option  2,  Performance  of  Logistics 
Module  Processing  at  Launch  Site,  was  evaluated  to  be  the  best 
option  for  Space  Station  operational  phase. 

Flexibility,  cost,  and  user  friendly  were  major  drivers  in 
selection  of  Option  2 which  was  rated  best  in  all  these  areas. 

Close  proximity  to  logistics  holding  area  or  spares  stores  areas 
minimizes  of  turnaround  time.  Shipments  of  logistics  module 

between  the  launch  site  and  another  site  is  eliminated  reducing 

» 

handling  and  cost. 

Number  of  interfacing  locations  to  which  users  (Space  Station 
systems  and  payload/experiment)  would  need  to  support  is 
reduced . 

Logistic  Module  Development  - It  is  recommended  that  the  Logis- 
tics Module  Development  should  emphasize  modularity;  provisions 
for  early  and  late  user  access;  development  of  flexible  accommo- 
dations which  meet  maximum  user  hardware  fabrication  tolerances; 
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modular  data  bases  facilitating  changes  between  mission  flight 
complements;  reverification  of  mandatory  recertification 
requirements  and  criteria;  and  standardization  of  procedures. 

VERIFICATION  TESTING 


The  Verification  testing  options  considered  are: 

1.  Perform  full-up  verification  testing  on  ground  (Spacelab 
model)  with  high  fidelity  simulators. 

2.  Perform  testing  to  rack  level  on  ground  with  simulated 
interfaces  and  complete  testing  to  the  Space  Station 
elements  on-orbit  (same  level  tests  to  be  performed  on 
payloads  attached  to  Space  Station  and  platform)  (preferred 
option) . 

3.  Perform  all  testing  in  orbit  (no  master  rack  or  integrated 
ground  testing). 

4.  Perform  data  system  and  software  verification  on  ground, 
using  DMS  onboard  the  Space  Station  (using  special  links). 
Verify  physical  interfaces  on  ground  with  master  gauge. 

These  are  the  options  considered  for  the  operational  verifica- 
tion test  of  user  experiments  and  payloads  interface  with  Space 
Station,  while  they  are  being  built,  and  before  the  equipment  is 
put  into  service  on  Space  Station.  Final  interface  verification 
testing  capability  is  currently,  proposed  to  be  at  KSC.  However, 
since  there  are  several  types  of  payload  interfaces,  including 
rack  to  pressurized  module,  attached  payloads  to  Space  Station 
truss,  and  payloads  to  platform,  it  may  be  desirable  to  do  final 
verification  of  some  of  those  interfaces  elsewhere. 

The  purpose  of  verification  testing  is  to  demonstrate  that  the 
users  flight  equipment  and  software  are  compatible  and  effec- 
tive with  the  Space  Station  and  its  interfaces.  It  is  expected 
that  user  experiments  and  hardware  will  be  tested  during  its 
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build  up  by  the  users,  to  verify  it  does  meet  the  specified 
operations  and  interface  requirements  of  the  Space  Station 
Program.  However,  it  is  desirable  to  have  a final  test  on  the 
ground,  with  realistic  Space  Station  interfaces,  to  be  certain 
the  assembly  and  previous  verification  was  done  right.  If 
inadequate  user  hardware  or  software  were  launched,  and  it  was 
found  to  not  fit,  or  otherwise  be  unacceptable  for  use  in  Space 
Station  then  it  would  need  to  be  returned,  repaired,  and 
relaunched.  A ground  simulation  of  the  Space  Station  environ- 
ment that  the  user  will  meet  would  save  him,  and  Space  Station, 
that  trouble  and  expense.  To  do  this  final  verification,  the 
real  characteristics  of  the  Space  Station  side  of  the  interface 
must  be  accurately  simulated  to  the  maximum  extent  feasible. 

The  Space  Station  side  might  even  be  duplicated,  with  actual 
flight  hardware.  Testing  the  users  equipment  with  this  Space 
Station  simulator  demonstrates  to  the  user  what  resources  of 
power,  data  handling,  cooling,  and  communication  the  Space 
Station  will  provide  him,  and  their  operating  characteristics. 

It  verifies  whether  he  can  physically  connect  to  and  operate 
with  the  Space  Station  interface.  This  testing  gives  confidence 
that  if  the  user  equipment  operates  properly  with  the  final 
Space  Station  simulator  during  the  interface  verification  test, 
his  equipment  will  also  operate  properly  on  the  Space  Station 
itself.  The  better  the  simulation  of  Space  Station,  the  higher 
the  confidence.  In  a ground  environment  a perfect  simulation 
cannot  be  made  of  either  side  of  the  interface.  The  Space 
Station  simulation  can  be  close,  but  the  user  must  be  aware  of 
potential  gravity  variations  in  his  equipment  and  compensate  for 
them. 

The  final  interface  verification  test  is  intended  to  demonstrate 
that  the  user  can  work  with  the  Space  Station  interfaces  he  will 
meet  in  orbit.  The  user  will  be  given  all  the  information 
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possible  about  how  he  functions  at  the  Space  Station  interface, 
but  the  ultimate  responsibility  for  successful  operational 
performance  on  the  Space  Station  will  rest  with  the  user. 

Maximum  use  of  telescience  as  a method  of  remote  checkout  and 
operations  of  payloads  on  Space  Station  by  users  and  other 
verification  methodologies  are  described  in  Appendix  D, 
"Verification  Considerations". 

Option  1.  Full  verification  with  high-fidelity  simulators  - 
This  option  would  require  that  after  all  in-process  verification 
tests  have  been  done,  there  will  be  a final  interface  test,  with 
exact  duplication  of  all  aspects  of  the  Space  Station  interface 
to  the  user.  Duplication  of  mechanical  interfaces,  data,  power, 
thermal,  and  communications  systems  would  be  exact.  Surrounding 
users  equipment  would  be  duplicated  or  simulated  for  the  purpose 
of  demonstrating  unexpected  reactions.  The  exact  data  system 
conditions  would  be  duplicated,  encompassing  all  other  users  on 
the  data  bus.  Power  and  thermal  control  system  fluctuations 
would  be  duplicated  within  normal  ranges.  The  Space  Station 
electromagnetic  environment  would  be  duplicated,  both  the 
conductive,  and  to  some  extent,  the  radiative. 

Analysis  - This  option  is  attractive  because  it  has  the  best 
possible  fidelity  to  the  real  Space  Station  situation  the  user 
will  meet.  It  is  the  same  sort  of  user  testing  that  is  done  now 
in  the  Spacelab  program  before  it  is  launched.  The  actual 
flight  Spacelab  is  used,  not  a duplicate  or  simulator. 

The  major  difficulty  that  would  be  encountered  with  this  method 
of  final  verification  is  keeping  current  with  all  the  Space 
Station  payload  configuration  changes.  Maintaining  continuous 
duplicate  fidelity  of  simulator  behavior  to  the  actual  behavior 
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of  the  changing  configuration  of  payloads  onboard  the  orbiting 
Space  Station  would  require  great  effort  and  expense. 

To  duplicate  on  the  ground  the  actual  user  systems  and  user 
hardware  that  are  in  orbit  would  be  very  expensive  and  beyond 
the  budgets  of  most  user  programs,  since  users  would  have  to 
produce  duplicates  of  their  fight  hardware  fpr  use  on  the 
ground. 

Option  2.  Perform  testing  to  rack  level  on  ground  with 
simulated  Space  Station  interfaces  and  complete  testing  to  the 
Space  Station  interfaces  on-orbit.  (Same  level  tests  to  be 
performed  on  attached  payloads ) . 

This  option  assumes  that  the  users  will  perform  adequate  testing 
during  experiment  buildup,  perhaps  using  Space  Station-provided 
simulators,  to  verify  that  Space  Station  operation  and  interface 
requirements  are  met.  Final  verification  would  require  that 
ground  duplication  of  interfaces  to  be  met  on  Space  Station 
would  be  only  as  accurate  as  is  considered  cost  effective.  The 
duplication  of  mechanical  interfaces  could  be  very  accurate. 
Duplication  of  data,  power  thermal,  and  communication  systems 
would  be  to  interface  specification.  Other  adjacent  users  would 
be  simulated  to  only  a limited  extent.  Simulated  Space  Station 
Power  and  thermal  control  system  fluctuations  would  stay  near 
nominal  levels.  The  conductive  electromagnetic  environment 
would  be  only  partly  simulated.  Systems  software  would  be 
duplicated.  The  data  bus  loading  due  to  other  users  would  be 
simulated. 

Analysis  - This  verification  method  is  considered  to  be 
feasible.  With  in-process  expected  verification  tests 
performed,  along  with  a reasonable  final  test,  only  the  minor  or 
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subtle  malfunctions  would  not  be  caught.  It  is  believed  those 
could  be  "worked  around"  if  they  did  occur  in-orbit. 

Option  3.  Perform  all  testing  in  orbit  (no  rack  or  integrated 
ground  testing). 

All  racks,  attached  payloads,  and  platform  payloads  would  be 
tested  during  the  buildup  process  by  the  users  at  their 
facilities  to  Space  Station  Program  specifications.  Transport- 
able "moderate  quality"  simulators  of  the  Space  Station  struc- 
tural , electrical , and  data  interfaces  may  be  provided  by  the 
Space  Station  Programs  but  would  not  fully  duplicate  the  actual 
Space  Station  interface.  These  simulators  would  primarily  be 
used  for  verification  of  the  payload  characteristics,  to 
preserve  the  safety  of  Space  Station  itself.  After  these  tests 
are  complete,  the  users  would  ship  their  payloads  to  the  launch 
site  for  transportation  to  Space  Station.  Only  after  actual 
installation  on  Space  Station  would  the  user  be  able  to  check 
his  equipment  in  the  Space  Station  environment. 

Analysis  - In  most  cases,  the  results  of  this  method  would 
probably  be  satisfactory,  with  few  minor  malfunctions  or 
incompatibilities  found  that  could  be  worked  around  or  fixed 
on— orbit.  However,  in  some  cases,  the  actual  Space  Station 
environment  would  not  be  what  the  user  expected,  or  there  would 
be  an  aspect  for  which  he  had  not  prepared.  His  equipment  would 
then  be  useless  and  need  to  be  returned  for  rework  or  repair. 

This  option  presents  higher  risk  to  safety  of  operations  of  the 
Space  Station  systems.  Additionally,  on-orbit  time  may  be 
required  to  detect  and  correct  which  could  have  been  found  on 
the  ground. 
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This  option  would  cost  the  least  for  the  Space  Station  Program, 
but  may  not  have  the  least  overall  cost  to  the  U.S.  taxpayers 
when  the  costs  of  return,  repair,  and  relaunch  after  an  inter- 
face failure  on  Space  Station  is  considered. 

Option  4 - "Perform  data  system  and  software  verification  on 
ground,  using  the  DMS  onboard  the  Space  Station.  Verify 
physical  interfaces  with  ground  master  gauge." 

After  the  users  in-process  verification  tests  are  done  a final 
high  fidelity  interface  test  will  be  done  except  for  DMS.  For 
the  DMS  an  actual  part  of  the  Space  Station  will  be  utliized. 

The  data  link  behavior  of  the  new  experiment  to  be  tested  can  be 
operated  with  the  actual  flight  DMS  as  if  the  experiment  were 
already  onboard  Space  Station.  The  instrument  under  test  on  the 
ground  would  appear  from  the  DMS  aide  as  if  it  were  just  another 
instrument  on  Space  Station.  The  instrument  under  ground  test, 
would  be  connected  through  a separate,  dedicated  Telecommunica- 
tions Data  Relay  Satellite  System  ( TDRSS ) communication  link 
used  as  a test  circuit.  This  special  test  circuit  would  be 
separately  available  out  of  TDRSS  to  the  ground.  This  separate 
TDRSS  circuit  would  be  connected  to  the  data  port  of  the  instru- 
ment under  test  on  the  ground.  The  user  on  the  ground  would  use 
his  ground  control  system  in  the  normal  fashion  to  command  his 
experiment  through  all  the  data  links  he  would  expect  to  use  for 
normal  operation  on  Space  Station,  including  normal  TDRSS  links 
and  the  DMS  on  Space  Station.  His  data  would  then  go  into  the 
special  DMS  data  port  on  Space  Station.  The  user  commands  and 
data  would  then  take  an  extra  jump  on  the  separate  test  circuit 
through  TDRSS,  back  to  the  ground  and  then  into  the  instrument 
that  is  being  put  through  its  test  program  on  the  ground. 
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Analysis  - This  option  allows  use  of  the  real  flight  command  and 
data  system,  without  simulation,  for  ground  checkout  of  new 
experiments.  The  effect  of  system  interactions  and  data  loading 
could  be  realistically  checked  with  the  real  system.  It 
avoids  simulation  difficulties  in  an  area  that  often  gives 
trouble.  However,  providing  the  special  data  port  and  dedicated 
link  on  Space  Station  and  TDRSS  has  high  expense  and  difficulty. 
The  method  may  not  be  practical  in  the  real  Space  Station 
Operational  environment  due  to  the  limitation  of  integrating 
ground  tests  with  on-going  flight  operations.  The  alternative 
of  high  quality  data  system  simulation  on  the  ground  is  also 
expensive  however  major  portions  will  already  available  via  The 
Space  Station  Information  Sysytem  (SSIS). 

Conclusions  and  Recommendations 

The  concept  of  Option  2,  doing  payload  verification  by  testing 
to  Space  Station  specifications  during  the  process  of  buildup 
and  then  final  test  to  a reasonable  level  on  the  ground,  then 
completing  the  testing  in  orbit  was  rated  as  the  most  feasible 
to  execute  at  reasonable  cost  to  the  Space  Station  Program 
during  Space  Station  operations.  Feasibility  is  good  because 
adequate  and  mature  simulation  of  the  various  kinds  of  user 
interfaces  to  Space  Station  will  already  exist,  from  the  Space 
Station  buildup  phase. 

Flexibility  for  user  needs  is  good  because  the  user  can  perform 
reasonable  tests  during  his  buildup,  then  any  final  interface 
tests  involve  only  a few  kinds  of  user  interfaces  to  Space 
Station,  which  will  remain  stable.  The  effect  of  adjacent  users 
can  be  reasonably  simulated  in  the  final  interface  test.  It  is 
considered  user  friendly  because  the  Space  Station  interfaces 
are  defined  and  predictable;  the  user  can  do  whatever  tests  he 


2-101 


wishes  to  verify  his  payload  during  buildup,  as  long  as  he  meets 
the  final  interface  and  Space  Station  safety  standards. 

The  effectiveness  of  transition  to  operational  use  is  high  and 
mainly  a matter  of  stabilizing  the  Space  Station  procedures  and 
documents  to  a configuration  that  minimizes  cost  and  operational 
impact  for  both  the  users  and  Space  Station  Program.  Management 
of  final  interface  simulators  would  remain  under  the  Space 
Station  Program.  The  cost  of  simulator  facilities  would  be 
already  paid,  with  only  some  upgrade  needed  to  optimize  the 
balance  between  increasing  the  chance  of  catching  user  anomalies 
versus  the  cost  of  verification  equipment.  The  effectiveness  of 
verification  performance  will  be  good,  commensurate  with  the 
quality  of  the  simulation.  The  safety  for  Space  Station  and 
users  will  be  good  because  the  finding  of  safety  anomalies  is 
the  object  of  the  several  reviews  and  the  final  testing  will  be 
done  by  experienced  personnel . Ease  of  proprietary  operation  is 
good  because  the  users  need  to  reveal  only  as  much  of  their 
payload  content  as  is  required  by  safety  considerations. 

Option  1 was  considered  by  the  panel  to  be  excessively  costly 
and  ultimately  not  workable,  since  even  high-fidelty  simulation 
would  never  exactly  duplicate  the  flight  Space  Station.  The 
extreme  cost  of  that  simulation  could  not  be  justified  by  the 
few  extra  errors  in  user  hardware  it  would  catch.  Moderate 
quality  simulation,  at  much  lower  cost,  that  would  catch  almost 
all  anomalies  was  considered  adequate. 

Option  2 was  considered  by  the  panel  to  be  the  most  reasonable 
option  for  verification  test.  It  can  balance  moderate  cost  to 
the  Space  Station  Program  for  a reasonably  high  quality  of 
verification,  with  reasonably  low  costs  to  the  users  from 
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failures  to  catch  subtle  problems  until  they  are  found  on-orbit. 
The  cost  was  considered  lowest  for  this  option. 

Option  3 was  considered  to  have  unacceptably  high  risk  for  the 
users  and  the  Space  Station. 

Option  4 was  considered  to  be  impractical . It  would  not  truly 
duplicate  the  data  load  of  other  users  that  will  exist  when  each 
user  operates  on  Space  Station.  The  expense  and  difficulty  of 
incorporating  the  independent  testing  circuit  and  the  possible 
difficulty  of  inserting  test  data  among  other  operational  users 
data  was  thought  to  be  greater  than  the  extra  value  potentially 
received  by  finding  subtle  data  problems  by  working  in  the  real 
DMS  instead  of  a simulation. 

It  is  recommended  that  a user  verification  system  like  that 
outlined  in  Option  2 be  adopted  for  operational  use.  Variations 
of  this  method  can  be  made  that  are  particularly  suitable  to  the 
different  types  of  user  interfaces,  such  as:  rack-to-module; 
attached  payload  to  Space  Station  truss;  and  platform  payload  to 
platform. 

LATE  ACCESS /EARLY  REMOVAL 

Current  configuration  of  the  Logistics  Module  (LM)  does  not 
accommodate  access  to  the  module  after  integration  is  completed 
at  the  Processing  Facility;  in  short  after  L-2  months.  The  only 
existing  access  is  to  the  NSTS  middeck.  Pad  access  has  been  a 
requirement  of  payloads  dating  back  to  the  days  of  Gemini.  Both 
the  NASA  and  NASDA  Life  Sciences  organizations  have  stated  a 
requirement  for  late  access  at  the  pad  and  early  removal  at 
landing  for  live  and  preserved  biological  specimens. 
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Background  - The  following  data  is  provided  to  aid  in  analyzing 
the  preferred  option  for  late  access/early  removal.  The  NASDA 
has  stated  that  they  intend  to  use  NASA  animal  transport 
facilities.  Even  if  facilities  are  provided  by  the  NASA  Life 
Sciences  users  for  containment  of  animals  and/or  plants,  which 
control  temperature,  accommodate  food,  water,  and  waste,  these 
systems  will  need  to  be  maintained  in  a pressurized  environment, 
require  power,  and  an  ECLSS  . Use  of  the  Orbiter  middeck  will 
not  satisfy  the  requirement  for  access.  Ose  of  middeck  lockers 
for  transfer  of  rodents  to  Space  Station  is  limited  to  minimally 
six  (6)  animals/ locker . Space  Station  facilities  are  configured 
to  house  72  rodents  simultaneously  or  12  squirrel  monkeys. 
Transfer  of  72  rodents  require  12  middeck  lockers  with  a total 
power  requirement  of  approximately  450  watts.  Squirrel  monkeys 
or  larger  primates  cannot  be  accommodated  in  a middeck  locker. 

In  addition,  the  transfers  of  animals  from  the  middeck  animal 
enclosure  modules  to  Space  Station  animal  housing  facilities  for 
single  caging  would  be  extremely  time  consuming  and  potentially 
hazardous . 

Rack  mounted  animal  holding  facilities  will  have  been  used 
through  three  Spacelab  missions  before  Space  Station  operations 
commence.  These  units  are  capable  of  maintaining  animals  for  a 
period  of  up  to  10  days.  The  units  could  be  loaded  as  early  as 
L-72  hours  and  be  maintained  before  off-loading  into  the  Space 
Station  for  a period  of  72  hours.  The  ability  to  install 
existing  facilities  into  the  LM  using  existing  SL  facilities  for 
transfer  of  animals  would  be  a NASA  Code  E savings  in  excess  of 
$2M  { 2 million) . 

Design  of  additional  equipment  (i.e.,  docking  module)  providing 
ECLSS,  power,  and  pressurization  while  attached  to  the  LM,  may 
bear  a weight  penalty  for  the  program. 
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Option  1.  No  Provisions  for  Early  Access.  No  provisions 
implies  total  dependence  on  use  of  the  Orbiter  middeck  and  no 
flight  of  specimens  greater  than  350  grams  or  items  larger  than 
a middeck  locker. 

Analysis  - This  option  has  no  rating  for  user  friendliness  or 
flexibility.  Long  term  costs  to  the  user  and  Space  Station  will 
also  result.  In  view  of  the  biological  experiments  planned  on 
Space  Station  by  both  U.S.  and  International  users.  Option  1 
must  be  disregarded.  The  biological  experiments  planned,  which 
are  intended  to  implicate  the  long  term  effect  of  0-g  on  man  in 
space  cannot  be  honored.  This  may  seriously  jeopardize  Space 
Station  activities  and  other  man-space  explorations;  i.e..  Mars 
landings. 

Total  reliance  on  use  of  the  Orbiter  middeck  has  been  considered 
as  feasible  for  animals  no  larger  than  rodents.  Power  require- 
ments may  make  this  an  unacceptable  alternative.  Safety  and 
performance  become  a significant  factor  when  transitioning  the 
specimens  from  their  multicaging  to  the  Space  Station 
facilities. 

Option  2.  Provide  access  to  LM  Through  Design  Change.  Design 
change  is  defined  as  design  change  to  the  Logistics  Module 

Analysis  - At  this  point,  this  would  appear  the  most  costly 
option  to  NASA  and  the  Space  Station.  In  the  long  run,  because 
of  the  availability  of  existing  holding  facilities,  public 
opinion  for  animal  rights,  and  potential  launch  weight  if 
installations  are  in  co-structures,  this  may  prove  the  least 
costly  to  the  program.  Design  changes  must  consider  safety  of 
entry  and  not  rely  on  the  type  of  access  utilized  in  Spacelab; 
i.e.,  suspension  on  a "bowswain's  chair."  Timely  access  to  the 
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LM  may  also  prove  to  be  a safety  critical  issue  for  the  program, 
both  on  launch  and  landing  for  other  reasons;  i.e.,  toxic 
wastes,  contingency  power,  or  fire  suppression. 

Option  3.  Space  Station  Provides  Special  Carriers.  The  issue 
of  early/ late  access  can  involve  special  carriers  which  must  be 
available  for  varying  payload  uploads  and  downloads. 

Background  on  Carrier  Applications  - A variety  of  wastes  will  be 
produced  during  Space  Station  operations.  Preliminary  analysis 
(Report:  OSSA  Space  Station  Waste  Inventory,  J.  Bosley, 

G.  Curran  - Bionetics  Corp.,  R.  Maines,  Nina  Saint,  P.  Hofmann  - 
Maines  Assoc.)  of  wastes  accumulated  every  90  days  during 
operation  of  only  the  experiments  in  the  O.S.  elements  i.e., 
life  sciences  and  materials  processing,  resulted  in  the 
following  data: 

Gases  600  kg  with  1100  kg  peaks  @ flights  8,  16, 

and  20 

Liquids  7500  kg 

Solids  1500  kg  with  4000  kg  peaks  @ flights  8 and 

16 

This  data  identifies  waste  produced  in  experiments  conducted  on 
attached  payloads,  free-fliers,  and  the  lab  module.  Primary 
gases  include  cryo  fluids,  argon,  helium,  nitrogen,  and  others. 
Examples  of  solids  were  metal  shavings,  bolts,  fragments, 
syringes,  animal  waste,  saw  blades,  dry /wet  wipes,  and  vials. 
Liquids  included  items  such  as  chemical  fixatives,  low  level 
radioactive  suspensions,  staining  solutions,  cleaning  fluids. 
Whether  the  station  elects  to  vent  gases,  regenerate  waste  water 
or  return  all  materials,  the  potential  of  hazardous  waste 
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exists.  Efficient  containment  for  transfer  from  Space  Station 
and  disposal  requirements  are  best  resolved  by  one  organization. 

For  safety  reasons,  these  wastes  cannot  be  readily  commercially 
transported  and  should  therefore  be  disposed  of  at  the  location 
where  they  may  be  most  conveniently  off-loaded  from  the  NSTS. 

In  addition,  containers  for  all  wastes  should  be  provided  by 
Space  Station  to  ensure  proper  logistics  control  and  safety. 
Because  it  may  be  difficult  to  trace  all  waste  accumulation  for 
all  Space  Station  elements,  particularly  in  terms  of  routine 
activities;  i.e.,  use  of  wipes  and  water,  the  cost  of  such 
containers  and  waste  disposal  should  be  dispersed  among  the 
users  over  the  lifetime  of  the  station. 

Analysis  - In  accordance  with  guidelines  for  safety,  carriers 
interfacing  to  NSTS  must  be  provided  by  the  Space  Station. 

Their  use  would  be  coordinated  through  Space  Station  logistics, 
which  would  insure  management  of  efficient  turn  around  for  the 
continuous  downloading.  There  will  be  a cost  for  carriers; 
flexibility  to  user  must  be  sacrificed  for  safety. 

Option  4.  Customer  Provided  Carriers  - These  are  defined  as 
carriers  providing  temperature  control  and  of  limited  size; 
i.e.,  5-10  cubic  feet. 

Analysis  - Carriers  intended  for  temperature  control  of  unique 
samples  are  best  provided  by  the  customer  who  understands  the 
requirements  and  can  stage  the  logistics  for  their  use. 

Customer  provided  carriers  for  items  that  are  in  conformance 
with  pressurized  container  safety  requirements;  i.e., 
non-offgassing,  power  compatible  can  be  accommodated  in  the  LM 
and  the  middeck  lockers.  Customer  provided  carriers  provide 
flexibility  and  are  most  cost  effective  for  the  Space  Station 
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Program*  The  customer  must  also  provide  GSE  or  battery  paks  to 
accommodate  any  early  off-loaded  carriers  until  they  are 
returned  to  the  user  designated  required  location. 

DISTRIBUTION  OF  EARLY  REMOVAL  ITEMS  (POST-FLIGHT) 

During  the  Space  Station  operational  era,  the  opportunity  is 
available  to  transfer  biological  and  nonbiological  systems  to 
the  Space  Station  0-g  environment  for  long-term  studies  and 
sampling;  to  create  systems  both  biologically,  chemically,  and 
physically;  and  to  return  such  samples  and  systems  to  1-g  for 
extended  analysis  by  the  user.  Though  the  systems  may  be 
altered  in  the  0-g  environment  (i.e.,  animal  tissues  and  cells 
returned  versus  the  live  animals  originally  sent  up),  they  may 
still  require  unique  support  and  maintenance  during  return, 
landing,  and  post-landing  operations. 

Biological  systems  require  specific  support  for  survival  and 
maintenance  without  degradation.  Support  may  range  from  a 
pressurized  atmosphere  including  controlled  oxygen/carbon 
dioxide  levels,  water' vapor,  and  temperature  to  a nonpressurized 
atmosphere  dependent  only  on  sustained  controlled  temperatures. 

Examples  of  the  former  include  plants  and  animals.  Examples  of 
the  latter  include  refrigerated,  frozen,  and  incubated  systems 
as  cells  and  tissues.  Primary  users  include  life  sciences  and 
materials  processing  disciplines. 

Nonbiological  systems  may  also  require  sustained  temperature  or 
specific  gaseous-rich  environments  to  reduce  the  potential  of 
degradation  during  transit  and  return  to  the  1-g  environment. 
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Option  1.  Space  Station  Delivers  All  Early  Removal  Items.  Early 
removal  items  (ERIs)  include  films,  biologicals,  products,  etc., 
which  would  be  transferred  to  Logistics  at  the  landing  site  with 
Logistics,  in  turn,  handling  shipping  and  transferring  to  the 
customer . 

Analysis  - Handling  of  items  such  as  film  would  be  transparent 
to  the  customer.  Indeed,  this  would  be  user  friendly,  but  would 
result  in  cost  to  Space  Station  and  would  be  an  inflexible 
system  in  that  this  would  not  allow  the  user  "on  site"  receipt 
as  required.  Handling  of  biological  and  chemical  systems 
requires  training  and  experience.  In  addition,  the  cost  of 
shipping  flight  live  samples  or  delicate  materials  and  propri- 
etary samples  to  the  customer  could  prove  excessive  to  the  Space 
Station.  From  a performance  and  safety  aspect.  Space  Station 
would  also  be  held  responsible  for  the  state  of  the  return 
specimens/samples. 

Option  2.  Space  Station  delivers  ERI  Directly  to  the  Customer 
at  the  Landing  site. 

Analysis  - This  is  a feasible  option  in  that  all  handling  of 
samples  and  specimens  would  be  within  their  containment  units. 
Flexibility  is  limited  to  complete  customer  control  and 
responsibility.  Management  and  performance  may  be  jeopardized 
due  to  the  customer's  inability  to  adequately  adhere  to  and 
interpret  transportation  regulations  for  shipments  and  to 
conform  to  required  import/export  regulations.  The  latter 
issues  impose  a level  of  user  unfriendliness  which  may  not  be 
immediately  perceived. 
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Option  3.  Combination  of  Option  1 and  Option  2.  The 
combination  of  Option  1 and  Option  2 implies  that  on  a case  by 
case  basis  and  as  negotiated,  ERI  would  be: 

o Delivered  directly  to  the  user  at  the  landing  site 

o Shipped  by  Space  Station  directly  to  the  user's  home 
site 

o Delivered  to  the  user  at  the  landing  site  with 

assistance  by  Space  Station  for  eventual  shipment  to  the 
user's  home  site. 

Analysis  - The  combination  of  the  above  options  has  been  a mode 
of  operation  through  the  NSTS  activities  and  has  proved 
effective  for  the  user.  This  combination  allows  logistics 
control  of  hardware  items  required  for  return  and  also  assists 
the  user  in  processing  and  returning  his  samples  to  his  home 
site  in  a timely  manner.  Through  a negotiated  process,  a 
one-on-one  interaction  with  the  user  is  possible  in  avoiding 
potential  mistakes  which  could  occur  from  inaccurate  assessment 
of  requirements  from  postflight  processing  documentation  and 
from  transport  regulations. 

Conclusions  and  Recommendations 

The  subjective  evaluation  of  the  proposed  options  against  the 
criteria  resulted  in  the  following:  Option  3,  the  combination 

of  Space  Station  and  user  delivery,  was  rated  highest  in  terms 
of  flexibility,  user  friendliness,  management,  effectiveness, 
and  safety.  Option  2 (user  delivery),  received  higher  ratings 
for  cost  effectiveness  and  ease  of  proprietary  operations. 

Option  3 received  the  highest  overall  rating  and  was  selected. 
Arguments  in  favor  are  that  the  Space  Station  Program  must 
provide  logistics  functions  at  the  loading  site  for  all  Space 
Station  payloads  and  the  additional  costs  for  handling  and 
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delivering,  as  negotiated  user  items  requiring  early  removal, 
would  represent  only  minor  additional  costs  to  the  Space  Station 
Program.  This  option  would  be  friendly  to  the  user  since  it 
would  provide  for  negotiation  of  services  which  the  user  sees  as 
necessary  to  early  removal  item  processing.  It  is  recommended 
that  negotiation  of  services  be  achieved  at  the  execution  level. 
To  effectively  implement  Option  3,  assure  cost  effectiveness  to 
the  Space  Station  Program,  provide  flexibility,  and  clear 
responsibility  transfer  to  the  user,  the  following  are 
recommended : 

1.  The  user  has  to  be  responsible  for  loading  all  specimens 
into  flight  transfer  units  for  shipment  to  Space  Station. 
Maintenance  of  specimens  at  launch  site,  in  conformance  with 
NASA  requirements  for  use  of  specimens  in  0-g  flights 
involving  humans  is  user  responsibility.  The  user  may  elect 
to  buy  services  from  NASA  or  an  approved  commercial 
contractor  which  would  be  limited  to  animal  maintenance  in 
terms  of  feeding,  cage  changeout,  and  cleaning.  Veterinary 
care  would  be  limited  to  health  maintenance  checks. 

Required  surgical  procedures  would  be  performed  by  the  user 
with  NASA  approval  prior  to  any  ground  or  flight 
experimental  activity. 

2.  The  user  is  responsible  for  providing  transfer  containment 
units  to  be  used  for  transitioning  systems  from  the  Space 
Station  facilities  to  the  landing  site. 

o For  live  systems;  i.e.,  animals,  the  same  units  used 
during  transfer  to  Space  Station  should  be  used  for 
return.  These  units  should  be  capable  of  temperature 
control  and  exchange  air  with  a pressurized  atmosphere 
through  HEPA  filters.  Power  and  ECLSS  must  be  provided 
by  Space  Station. 

o Plants,  tissues,  and  cells  maintained  at  ambient  to  +45 
degrees  or  down  to  -20  degrees  must  be  provided  an 
external  environment  allowing  such  control  along  with 
power  while  on-orbit.  It  is  assumed  power  is  available 
at  landing  until  systems  are  off-loaded.  The  user  will 
provide  ground  support  equipment  to  maintain 
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environmental  control;  i.e.,  battery  paks,  blanket 
purges,  ambient  air/temperature  control. 

o Maintaining  and  refurbishing  transfer  units  to  flight 
configuration  and  verification  is  user  supplied. 

o Providing  and  maintaining  logistics  for  use  of  the  user 
provided  transfer  units  is  user  responsibility . 

o Shipment  and  costs  of  transporting  hardware  and 

specimens  to  the  launch  site  are  user  responsibility; 
post-flight  shipments'  arrangements  should  be  jointly 
negotiated  with  Space  Station  Logistics  at  landing. 
Typical  shipping  services  include: 

o Scheduling  a commercial  carrier  for  return  to  the  user’s 
site 

o Administrative  assistance  in  "export"  requirements 

o Final  packaging /labeling  per  regulations. 

Support  Functions 


FLIGHT  HARDWARE  RECERTIFICATION 


Recertification  is  the  process  by  which  acceptability  for  next 
use  of  flight  hardware  is  certified.  Recertification  verifies 
that  performance  of  all  activities  such  as  but  not  limited  to 
inspections,  tests,  maintenance,  servicing,  calibration,  re- 
placement of  limited  life  or  failed  parts  and  components;  etc., 
of  Space  Station  hardware  and  software  have  been  accomplished 
satisfactorily . 

Criteria  for  inspections,  tests,  maintenance,  servicing,  cali- 
bration, replacement;  etc.,  of  Space  Station  systems  hardware 
and  software  between  flight  and/or  on  a periodic  basis  are  one 
of  the  key  factors  required  for  success  of  long  life  operations 
and  cost  management.  The  criteria  and  procedures  need  to  be  in 
place  for  first  flight.  Update  as  changes  are  made  and  problems 
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occur  during  the  development  flights  should  be  accomplished  in 
such  a manner  as  to  support  the  transition  of  Space  Station  from 
development  to  operational  status.  Emphasis  in  this  area  and 
coordination  with  logistics  on  sparing  and  reverification  is  an 
essential  part  to  the  proper  selection  of  spares  for  the  long 
life  of  Space  Station.  A separate  method  of  providing  manage- 
ment visibility  and  control  of  the  recertification  criteria  and 
specifications  is  needed.  The  sustaining  engineering  organiza- 
tion should  have  responsibility  for  overall  management  of 
recertification  with  both  flight  and  ground  operations  providing 
timely  implementation  and  information  on  results  of  recertifica- 
tion and  comparison  trends  versus  problems  experienced. 

For  international  users,  the  NASA  problem  report  and  corrective 
action  system  will  provide  visibility  into  station  problems  on 
his  provided  hardware.  NASA  Space  Station  sustaining  engineer- 
ing will  request  corrective  action  where  overall  Space  Station 
systems  performance  is  impacted. 

For  U.S.  provided  hardware  and  software,  the  tracking  and 
reporting  on  problems  will  be  within  the  NASA  problem  report  and 
corrective  action  system.  Responsibility  for  assessing,  con- 
trolling requirements,  and  evaluating  effectiveness  of  recerti- 
fication of  Space  Station  system  hardware  is  assumed  to  be  a 
sustaining  engineering  function. 

Major  functions  of  recertification  include: 

o Maintain  and  update  recertification  criteria. 

o Maintain  and  update  procedures  for  inspection,  tests, 
and  calibrations. 
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o Maintain  and  update  historical  records  as  required  by 
specification  and  requirements  documents  and  quality  and 
reliability  and  safety  documents  where  applicable. 

o Verify  that  records  indicate  required  tests, 

inspections,  maintenance,  calibration,  replacements, 
rework,  modifications;  etc.,  have  been  accomplished. 

o Establish  and  maintain  standard  operation  procedures  for 
recertification. 

o Initiate  and  maintain  certification  records. 

Three  locations  for  performing  recertification  were  considered. 
Sustaining  engineering  would  manage  and  control  criteria  and 
specifications  for  recertification  under  all  options.  Payload 
provider  retains  responsibility  to  certify  his  hardware  for 
reflight  and  or  reuse  in  same  manner  as  on  initial  or  new 
hardware  deliveries. 


Option  1.  Launch  Center  performs  Recertification.  All 
documentation,  verifications,  tracking  and  reporting,  records  of 
certification  are  responsibility  of  launch  site. 

Launch  center  certifies  recertification  status  at  flight  readi- 
ness reviews* 


Space  Station  sustaining  engineering  organizations  provide 
changes  in  criteria  and  specifications  needed  for  certification. 

Analysis  - This  option  provides  a central  source  for  documents, 
problem  reports,  test  reports,  data  packages;  etc.,  needed  for 
recertification . 

The  most  experienced  test  personnel  (during  operational  phase) 
will  be  at  launch  center. 
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Recertification  before  higher  level  integration  is  a constraint 
to  most  milestones  and  status  needs  to  be  known  for  work  plan- 
ning impact  assessment* 

Launch  operations  personnel  are  more  subject  to  immediate 
processing  flow  schedule  priorities  than  independent  integration 
personnel . 

Option  2.  Commercial  Integrator  Performs  Recertification*  All 
documentation*  verifications*  tracking  and  reporting,  records  of 
certification  are  responsibility  of  commercial  integrator. 

Commercial  integrator  presents  and  documents  status  of  certifi- 
cation to  Space  Station  organization. 

Space  Station  organization  reports  certification  status  at 
integration  and  flight  readiness  reviews. 

Commercial  integrator  responds  to  and  implements  approved 
changes  to  recertification. 

Analysis  - An  organization  independent  of  launch  pressures 
performs  the  function. 

Data,  records*  reports;  etc.,  would  be  duplicated  to  extent 
necessary  for  NASA  traceability.  Contractual  directions  needed 
to  effect  changes  and  increases  certification  interfaces. 

Option  3.  Payload  Integrator  (i.e.*  S&T  Center,  International 
Partner,  etc.)  recertifies  all  program-provided  flight  hardware 
just  prior  to  installing  experiment  hardware.  All  documen- 
tation, verifications,  tracking  and  reporting,  records  of 
certification  are  responsibility  of  integrator. 
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Integrator  certifies  hardware  ready  for  flight  or  identifies 
open  verifications  at  time  of  delivery  to  the  Launch  site. 

Integrator  performs  or  negotiates  with  launch  center  performance 
of  any  open  verification  items  after  delivery. 

Launch  center  verifies  performance  of  open  items  it  accepts. 

Integrator  certifies  recertification  status  at  flight  readiness 
reviews . 

Analysis  - An  organization  independent  of  launch  pressures 
performs  the  function. 

This  option  increases  locations  where  certification  status  has 
to  be  visible  for  processing  flow.  Certification  problems 
experienced  in  launch  area  are  better  known  by  launch  personnel . 

Conclusions  and  Recommendations  - Option  1 (Launch  Center 
Recertification)  was  selected  as  the  best  option.  Option  3 
(Distributed  Integrator  Recertification)  was  evaluated  to  be  the 
least  desirable,  because  timely  management  and  control  would  be 
more  difficult.  The  one  major  factor  in  selection  of  launch 
center  option  for  recertification  is  that  records,  hardware, 
problems  experience  are  more  concentrated  in  the  launch  center 
during  operational  phase.  Additionally,  the  Sustaining  Engi- 
neering organization  manages,  evaluates  and  controls 
recertification  where  ever  implementation  is  located. 

USER  SUPPORT  FACILITIES 

User  support  facilities  are  defined  as  facilities  located  at  the 
launch  or  landing  site  areas  to  support  payloads  pre  and 
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postflight  processing  activities.  Facilities  addressed  are  for 
multiple  purposes.  The  NASDA  has  indicated  requirements  for 
facility  space  for  final  integration  and  checkout  of  their 
Experiment  Logistics  Module  (ELM),  plus  animal  handling 
facilities  and  phytotrons.  U.S.  users  in  the  Materials 
processing  and  Life  Sciences  disciplines  (Code  E)  will  require 
facilities  supporting  pre/post-flight  operations  involving 
biologicals  (animals,  plants,  tissues)  and  crew  baselining. 

A crew  Baseline  Data  Collection  Facility  ( BDCF ) , approximately 
5000  square  feet  will  be  required  at  the  launch  and  the  landing 
sites  (Dryden-Ames  Research  Center  and  Kennedy  Space  Center). 
BDCFs  with  their  complement  of  equipment  must  be  in  place  120 
days  prior  to  launch  and  must  be  available  immediately  at  crew 
landing.  Deconditioning,  (dependent  on  the  body  function),  can 
occur  within  10-20  minutes  after  reintroduction  to  1-g.  Current 
Life  Sciences  planning  is  to  closely  analyze  all  mission  crew 
physiological  changes  in  an  effort  to  determine  the  viability  of 
the  long-term  Humans  in  Space  program.  In  short,  a BDCF  would 
be  a long-term  use  facility. 

Similarly,  the  science  community  addressing  functions  in  nonhu- 
man systems,  will  require  facilities  for  immediate  post-flight 
analysis  and  testing  of  live  specimens.  NASA  , during  NSTS 
operations,  established  a precedent  that  such  specimens  conform 
to  defined  microbiological  requirements  preflight.  Animals  must 
be  maintained  and  cared  for  under  very  stringent  procedures  as 
defined  by  the  American  Association  for  Accreditation  of  Labora- 
tory Animal  Care  (AALAC),  as  evidence  that  NASA  associated 
animal  activities  are  conducted  with  utmost  concern  for  humane 
care  and  treatment.  Facilities  currently  used  for  Spacelab/NSTS 
activities  involving  animals,  tissues,  and  plants  are  sized  to 
accommodate  pre/post-launch  and  early  access /removal  activities 
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for  Space  Station.  Because  of  the  long  duration  (45-90  days), 
ground  controls  should  be  conducted  at  the  appropriate  S&T 
Center  (Ames  Research  Center). 

It  is  assumed  that  NASA  will  impose  the  same  requirements  for 
NASDA  and/or  ESA  biological  specimens  as  those  placed  on  their 
U.S.  experimenters,  since  the  crew  interface  is  at  issue.  This 
must  be  implemented  if  the  Internationals  use  the  NASA  animal 
transport  facilities  as  they  have  indicated.  This  also  implies 
sequencing  animal  experiments  by  the  Japanese  and  O.S.  experi- 
menters due  to  transporter  availability.  Total  animal  loads  at 
a ground  facility  pre  and  post-launch  should  not  exceed  that 
observed  for  Spacelab. 

Other  potential  preflight  operations  for  all  sciences  (life 
sciences  and  materials)  which  require  unique  support  would 
include  sterilization  (autoclaving,  ethylene  oxidation,  and 
irradiation),  system  evacuation  and  pressurization,  and  incuba- 
tion. These  capabilities  could  potentially  be  procured  off 
site. 

To  address  the  long-term  use  of  facilities  it  may  be  best  to 
consider  "discipline"  facility  use,  regardless  of  the  activity, 
whether  NSTS  Spacelab,  Space  Station,  ELV's,  or  Aerospace  plane. 
In  a discipline  multi  use  mode  the  logistics  for  scheduling  use 
of  such  facilities  when  available  for  multiple  activities  is 
foremost.  Secondly,  the  availability  of  contractor,  off-site 
facilities  for  continuing  support  will  be  dependent  on  the 
ability  of  the  contractor  to  show  a substantial  profit  margin. 

No  clear  choice  among  the  options  considered  for  user  support 
facilities  emerged  from  the  evaluation  process  because  of 
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requirement  variables.  A description  and  assessment  of  each 
option  follows. 

Option  1.  Oser  Contracts  with  Off-launch  Site  facilities  for 
support  - This  option  allows  the  user  to  contract  for  a facility 
in  which  he  may  perform  any  prelaunch  activities  or  to  contract 
for  services;  i.e.,  sterilization/cleaning  activities  cited.  If 
NASA  dictates  this  must  be  the  mode  of  operation,  there  would 
have  to  be  some  assurance  that  such  facilities  and/or  services 
exist  within  the  launch  area.  Additionally,  this  implies  that 
hardware  must  be  moved  from  the  off -site  area  to  the  Launch 
Processing  Facility  (LPF).  The  latter  activity  places  an  added 
cost  on  the  user  or  potentially  on  NASA,  depending  who  transfers 
equipment  from  off-site  to  the  launch  processing  facility. 

Analysis  - The  off-site  facility  for  the  BDCF  equates  to  no 
facility  at  all  because  of  the  degradation  in  performance;  i.e., 
the  requirement  for  rapid  crew  access  post-landing*  This  may 
also  be  true  for  the  animal  handling  facilities  in  view  of  the 
stringent  AALAC  requirements  which  limit  access  by  the  general 
public  to  such  facilities.  A secured  area  for  the  animals  may 
be  required  during  the  Space  Station  activities  as  was  required 
during  Spacelab.  Off-site  facilities  may  in  fact  result  in 
added  cost  to  NASA,  may  result  in  difficulties  due  to  certifi- 
cation requirements  for  specimens  and  facilities.  The  option 
does  not  allow  the  flexibility  necessary  for  late/early  access 
and  contingency  delays.  In  turn,  safety  and  performance  may  be 
severely  jeopardized  by  use  of  off-site  facilities  for 
biological  specimens.  The  option  is  only  viable  for  hardware 
activities  occuring  well  in  advance  of  a launch. 

Option  2.  Facility  Provided  at  Launch  Site  at  Rental  Fee. 

This  option  is  representative  of  the  Hangar  L facility  at  KSC 
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and  BDCF  and  Flight  Receival  Facility  at  Axnes-Dryden  used  during 
Spacelab  activities. 

Analysis  - This  option  allows  flexibility  because  of  the 
nearness  to  the  launch/ landing  site.  Transition  is  viable, 
based  on  Spacelab  experiences.  The  option  eliminates  the 
potential  that  a commercial  facility  may  simply  not  continue  to 
exist  for  the  operational  lifetime  of  Space  Station.  It 
eliminates  any  contract  or  legal  obligation  NASA  may  face  in 
stating  that  the  user  must  find  a facility  off-site;  i.e.,  if 
there  were  potentially  multiple  contenders  to  offer  services. 

It  would  allow  easier  configuration  for  a dedicated  user;  i.e., 
the  80CF  or  animal  handling.  It  also  assures  maintenance  of 
NASA  requirements;  i.e.,  AALAC  under  Government  control  and 
surveillance.  For  the  animal  handling  capabilities,  this  is 
feasible:  such  facilities  do  exist  and  support  Spacelab 
activities. 

Option  3.  Trailer  Lot  Hookups  at  Launch  Site.  This  option 
involves  setting  up  a trailer-lot  facility  with  power  hook-ups. 
The  user  brings  his  trailer  and  support  equipment  to  the  site. 
The  option  is  particularly  viable  for  proprietary  operations 
involving  late  stowage,  pad  access,  and/or  resupply  in  a con- 
tingency mode.  The  option  is  viable  for  "stand  alone"  hardware 
check-out  and  for  science  related  activities  as 
plants/phytotrons  and  insect  maintenance.  The  limitations,  in 
terms  of  environmental  standards  must  be  recognized. 

Trailers  may  be  interpreted  to  provide  flexibility;  they  are 
user-friendly  dependent  on  the  specific  applications. 
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3.0  LOGISTICS 


3.1  EXECUTIVE  SUMMARY 

The  provision  of  logistics  support  to  the  operational  Space 
Station  represents  one  of  the  major  cost  drivers  of  the 
operational  era  and  is  the  most  sensitive  to  the  adequacy 
of  the  design  consideration  given  during  the  Phase  C/D 
activities.  The  Logistics  Subpanel  has  addressed  the  full 
spectrum  of  logistics  issues  from  design  to  mature 
operations  and  across  all  program  elements,  including  the 
institutional  support  elements  necessary  for  the  thirty 
year  estimated  life  of  the  program.  During  the  course  of 
its  deliberations,  the  subpanel  reviewed  and  commented  on 
the  Work  Package  requests  for  proposals  (RFPs). 

In  addition  to  the  briefings  supplied  to  the  Task  Force  in 
general,  we  have  attempted  to  gather  information  from 
throughout  the  Space  Station  Program  and  the  logistics 
community  at  large.  The  subpanel  would  like  to  express  its 
appreciation  to  all  those  who  took  the  time  to  share  their 
experience  and  expertise  with  us.  Our  ability  to 
contribute  to  this  endeavor  was  significantly  enhanced  by 
those  from  outside  the  Task  Force  who  participated.  The 
subpanel  would  also  like  to  acknowledge  the  outstanding 
work  that  has  been  done  to  date  by  those  in  the  program. 

An  enterprise  such  as  the  Task  Force  will  always 
concentrate  on  the  things  yet  to  be  done.  It  is 
appropriate  to  recognize  at  the  beginning  that  many 
dedicated  people  have  labored  hard  to  bring  the  program  to 
this  point.  Our  task  is  to  seek  to  find  ways  to  enhance 
their  efforts  to  the  end  that  the  Space  Station  Program  is 
better  served  by  us  all. 
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Those  from  the  logistics  community  who  read  the  report  will 
likely  say:  "I  told  you  so",  while  those  associated  with 
the  program  planning  to  date  will  find  some  food  for 
thought.  The  subpanel  suggests  that  there  remains  a 
significant  challenge  for  the  program  in  providing  the 
emphasis  in  designing  for  supportability  if  the  baselined 
requirements  for  reliability  and  maintainability  are  to  be 
realized.  The  RFPs  do  not  represent  a consistent  set  of 
design  requirements.  If  they  are  not  supplemented  to 
correct  this  deficiency,  the  Space  Station  system  will  be 
more  costly  to  operate  and  maintain  than  it  should  be,  and 

have  less  than  the  desired  experiment  operations 
capability. 

The  subpanel  has  recommended  several  changes  in  approach  to 
the  program  which,  if  implemented,  should  enhance  the 
design  effort.  A Phase  C/D  management  scheme  is  presented. 
Additional  facilities  for  warehousing  and  repair  are 
proposed  and  a suggestion  for  the  management  of  maintenance 
and  resupply /return  is  discussed.  The  subpanel  hopes  the 
proposals  outlined  in  the  summary  that  follows  prove 
helpful  to  the  program. 

SUMMARY  OF  FINDINGS 

o Request  For  Proposals.  Phase  C/D 

- All  Work  Package  proposals  need  to  have  a common 
Logistics  emphasis  for  design  emphasis 

- Logistics  Support  Analysis  is  a start  - if  it  is 
consistent  across  Work  Packages  and  integrable 

o Logistics  Operations  Center  (LOC) 

- Establish  immediately  as  the  Program  Office 
organization 
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- LOC  to  integrate  acquisition  logistics  and 
operational  logistics  capability  development 

- LOC  to  include  on-site  intermediate  & depot 
capability  and  management 

- Phases  out  original  equipment  manufacturers 
(OEMS) 

Incorporates  Automated  Test  Equipment  with  OEM 
provided  test  equipment 

- Ensures  flight  recertification  testing  of  ORU's 

- Monitors  maintenance,  operations  and  upgrades  to 
Space  Station  critical  institutional  systems. 

- Manages  and  participates  in  strategic,  tactical 
and  execution  planning 

- Manages  common  items 

- Monitors  transportation  traffic  control 

Reports  to  Associate  Administrator  of  Space 
Station 

- Maintains  a LOC  capability  development  plan  and 
implementation 

o Logistics  Carrier  Prepacking 

- Work  area  required  in  LOC 

o Integrated  Logistics  Working  Group  (ILWG) 

- Revitalize  the  ILWG 

- Needs  dynamic  chairperson 

- Program  Office  charter  via  NASA  Management 
Instruction  (NMI ) 

Secretariat  function  by  Payload  Ground 
Operations  Contractor  and/or  Program  Support 
Contractor 

- Membership  from  Work  Package  <WP)  Centers  and 
Kennedy  Space  Center 
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- Supported  by  WP  contractors  as  appropriate 

- Manages  resupply/ return  requirements 
determination 

- Manages  on-orbit  storage  requirements 
determination — not  adequately  managed  today 

- Ensures  acquisition  and  operational  logistics 
requirements  are  met  and  related  contract 
provisions  are  fulfilled. 

o Inventory/Logistics  Management  System 

- Interfaces  with  Kennedy  Inventory  Management 
System  (KIMS).  KIMS  is  incomplete  for  Space 
Station  today,  does  not  include  on-orbit  storage 

- Interfaces  with  TMIS 

- Interfaces  with  CAD /CAM/ CAE/ CAL ' s 

- Space  Station  inventory  management  must  cover 
all  ground  and  orbital  items. 

o Customer  and  International  Users 

- Coordinate  requirements  for  logistics  support 
through  ILWG 

- Includes  servicing  interfaces  for  logistical 
goods  and  services 

o Maintenance  Paradox 

- Maintenance  man-hours  typically  decrease  as 
complexity  lessens 

- Space  Station  design  requirement  is  an  anomaly 

o Space  Station  Warehousing 

- Additional  $30M  facility  required 

- Current  Space  Station  estimate  is  50K  line 
items;  SSOTF  estimate  is  300K  line  items 

Inventory  buildup  phasing  depends  on  block 
design  phasing 
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o Technical  Documentation 


- Acquire  documentation  to  avoid  OEM  dependency 
o Availability /Reliability 

- Incentivize  contractor  to  deliver  highly 
reliable  system  elements 

3.2  CONCEPT  DESCRIPTION 
3.2.1  Introduction 

A logistics  support  concept  for  any  system  is  largely  a matter 
of  system  design.  While  some  aspects  of  logistics  support  in 
the  operational  phase  of  the  Space  Station  Program  lend 
themselves  to  variations  in  approach,  the  basic  scope, 
character  and  limitations  of  the  logistics  support  concept  are 
a result  of  decisions  made  during  the  design  phase  of  the 
program.  Equally  as  important,  are  the  decisions  that  are  not 
made.  The  omission  of  design  requirements  addressing  logistics 
support  issues  will  lead  to  a system  that  is  as  unsupportable 
as  one  predicated  on  inappropriate  system  design  decisions. 

The  task  of  the  Logistics  Subpanel  — to  envision  the  fully 
operational  Space  Station  support  system  in  the  year  2010  — 
was  made  more  challenging  by  the  fact  that  the  design  decisions 
which  characterize  the  supportability  of  a system  have  not  yet 
been  made  in  the  Space  Station  Program.  To  propose  an 
operational  logistics  support  approach  is,  consequently,  a 
risky  business.  However,  it  affords  the  subpanel  the 
opportunity  to  assume  that  the  proper  attention  has  been  given 
to  supportability  issues  at  the  appropriate  times,  from 
beginning  to  end,  in  the  design  process.  Notwithstanding  the 
peril  of  these  assumptions,  the  subpanel  has  ventured  into  the 
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future  and  attempted  to  describe  the  salient  aspects  of  a 
logistics  support  approach  which  will  satisfy  the  program 
constraints  as  we  understand  them. 

In  the  course  of  our  deliberations  we  have  suggested  approaches 
different  than  those  currently  contemplated  by  the  program  to 
accomplish  several  logistics  functions.  The  approaches 
suggested  by  the  subpanel,  and  our  concerns  in  key  areas,  are 
summarized  here. 

Overview 


The  Space  Station  operation  era  logistics  support  will  be 
characterized  by  the  human,  material  and  information  resources 
and  associated  activities  required  to  transport  material  to  and 
from  orbit,  repair  and  maintain  the  on-orbit  hardware  and 
repair  and  maintain  the  ground  systems.  The  maintenance  of 
program  hardware  and  the  resupply/return  of  consumable 
supplies,  experiment  hardware,  maintenance  and  repair 
materials,  tools  and  manpower  and  the  transfer  of  crew  persons 
will  constitute  a major  portion  — at  least  fifty  percent  — of 
the  operational  era  costs  according  to  recent  Space  Station 
Cost  Commitment  Team  findings. 

To  manage  the  operational  logistics  task,  the  Logistics 
Operations  Center  (LOC)  is  proposed.  Reporting  to  the  Program 
Office  NASA  Headquarters  and  located  at  KSC,  the  LOC  provides 
the  execution  level  integration  to  assure  logistics  support  to 
the  Space  Station  and  provides  strategic,  tactical  and 
execution  level  planning  support  to  the  appropriate  levels  of 
management.  An  on-site  intermediate/depot  level  repair  facility 
at  KSC  is  proposed  to  perform  failure  analysis  using  automated 
test  equipment  (ATE),  to  manage  the  repair  process  and  to 
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perform  recertification  testing  before  returning  hardware  to 
orbit.  A uniform  approach  to  the  maintenance  and  upgrade  of 
the  institutional  systems  which  support  the  Space  Station  is 
suggested  as  appropriate,  with  the  LOC  serving  in  a program 
oversight  capacity.  The  facilities  and  data  management  required 
by  this  approach  are  proposed  to  be  located  at  the  ground 
operations  center.  Data  entry  and  access  will  be  widely 
distributed. 

Recommended  Changes  in  Approach. 

Integration  of  Acquisition  Phase  Logistics  with  Logistics 
Operational  Capability  Development  - The  necessity  to  resolve 
on-orbit  maintenance  and  resupply/ return  requirements  at  the 
strategic/tactical  level  and  the  multi-center  integration  of 
logistics  support  requirements  led  the  Logistics  Subpanel  to 
propose  the  creation  of  a headquarters  Logistics  Office  at  the 
Program  Office  level  and  the  Logistics  Operations  Center  (LOC) 
located  at  the  ground  operations  center.  The  functions  and 
roles  of  these  two  organizations  for  the  operations  phase  of 
the  Space  Station  Program  are  presented  in  the  discussion  which 
follows . 

The  recommendation  concerns  modifying  the  management  approach 
to  the  Phase  C/D  logistics  design  activities  (Acquisition 
Logistics)  and  the  logistics  operational  capability  development 
effort.  As  currently  structured,  the  management  of  Phase  C/D 
logistics  activities  has  been  delegated  to  the  individual  Work 
Package  centers.  The  Integrated  Logistics  Working  Group  (ILWG) 
developed  the  Phase  B program  and  policy  documentation  for 
logistics,  but  the  translation  into  the  Phase  C/D  Requests  for 
Proposals  was  not  accomplished  in  a consistent  fashion. 


The  task  of  operational  logistics  capability  development  has 
not  been  clearly  defined  or  delegated.  The  integration  of  Work 
Package  requirements  with  operational  logistics  capability 
planning  has  been  diligently  pursued;  however,  the  priority  for 
this  activity  has  not  been  sufficiently  high  on  the  list  of  the 
Work  Package  centers  to  meet  the  needs.  Indeed,  one  would 
expect  the  Work  Package  centers  to  be  more  concerned  with 
developing  their  hardware,  and  thus  the  dilemma.  Figure  3-1 
displays  the  various  facets  of  the  logistics  support 
development  process.  It  is  the  subpanels  observation  that  only 
the  Assets  portion  of  the  program  is  being  pursued  and  that  the 
Organization  and  System  portions  of  the  program  require  a 
comparable  level  of  attention. 

The  Logistics  Subpanel  recommends  the  LOC  be  created 
immediately  as  a function  of  the  Program  Office.  In  order  to 
perform  the  execution  level  integration  of  Phase  C/D  logistics 
activities  and  transition  them  into  a complete  operational 
logistics  capability,  the  structure  shown  in  Figure  3-2  is 
proposed.  The  LOC  manager  would  report  to  both  the  Program 
Office  manager  for  Systems  Engineering  and  Integration  (SE&I) 
and  the  Program  Office  manager  of  Utilization  and  Operations. 
Operations  center  personnel  would  be  teamed  with  contractor 
support  from  the  SE&I's  Program  Support  Contractor  (PSC),  staff 
from  the  operations  center's  Payload  Ground  Operations 
Contractor  (PGOC)  and  a major  aerospace  company  that  has 
previously  been  involved  with  the  logistics  integration  of  a 
large  scale  program  to  accomplish  the  task.  Using  the 
logistics  integration  staff  to  define  the  RFP  requirements  for 
analysis  and  integration,  the  PSC  and  PGOC  personnel  would  be 
used  to  monitor  package  contractors'  performance  and  to 
incorporate  the  resulting  design  decisions  into  a comprehensive 
comprehensive  LOC  capability  development  plan.  In  this  manner. 
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Figure  3-1.  Major  Logistics  Focus  by  Program  Phase 
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Figure  3-2.  Management  Structure 


the  consistent  application  of  logistics  design  criteria  across 
the  Work  Packages  can  be  enhanced  and  the  capability  to  support 
hardware  can  be  solidly  based  on  the  scheduled  flow  of  that 
hardware  and  technical  systems  through  the  operations  center  to 
orbit.  As  the  assembly  and  verification  phase  of  the  program 
comes  to  an  end,  the  logistics  integration  contractor  and  the 
PSC  participation  can  be  concluded  and  the  NASA/PGOC  team  would 
be  well  prepared  to  provide  the  long  term  logistics  support  to 
the  program.  This  orderly  flow  of  responsibility  also  avoids 
the  disfunctional  impacts  associated  with  logistics  responsi- 
bility transfer  that  have  been  experienced  within  the  Space 
Shuttle  Program. 

Repair  Depot 

The  long  term  supportability  of  the  Space  Station  will  depend 
to  a large  degree  on  how  effectively  hardware  returned  from 
orbit  can  be  repaired  and  maintained  on  the  ground.  In 
examining  the  current  support  approaches  proposed  in  the  Work 
Package  RFP's  and  discussing  long  term  support  issues  with 
personnel  in  the  Space  Shuttle  and  Air  Force  reconnaissance 
programs,  the  Logistics  Subpanel  concluded  that  an  on-site 
intermediate /depot  repair  facility  should  be  included  in  the 
current  program  planning. 

The  use  of  automated  test  equipment  to  analyze  failure  modes 
and  to  recertify  repaired  equipment  prior  to  return  to  orbit 
provides  a synergistic  savings  to  the  program.  The  need  to 
acquire  the  technical  documentation  necessary  to  maintain, 
repair  and  reacquire  the  Space  Station  hardware  has  been 
strongly  recommended  to  the  Task  Force.  The  need  to  plan,  from 
the  beginning,  to  provide  on-site  repair  capability  and  to  phase 


out  the  original  equipment  manufacturer  (OEM)  in  most  cases  has 
also  been  strongly  recommended.  It  is  recognized  that  there 
will  be  some  hardware  for  which  the  retention  of  the  OEM  as  the 
repair  source  will  be  the  best  decision.  This  will  be  the 
exception,  however.  The  subpanel  recommends  the  addition  of  an 
on-site  depot  repair  facility  at  KSC  that  incorporates  these 
features,  to  support  the  maintenance  of  Space  Station  hardware. 

Log  Carrier  Prepack. 

The  reconfiguration  of  the  Space  Station  Processing  Facility  to 
serve  as  an  experiment  verification  and  checkout  facility  will 
provide  an  excellent  user  support  facility.  The  ground 
processing  flow,  however,  should  not  be  encumbered  with  the 
routine  packing  of  non-experiment  materials  destined  for  orbit. 
The  Logistics  Subpanel  recommends  that  a logistics  carrier 
prepacking  area  be  included  in  the  proposed  Space  Station 
logistics  facility.  The  off-line  prepacking  of  racks' and 
drawers  for  installation  in  the  pressurized  logistics  carrier 
as  well  as  the  preparation  of  the  nonhazardous  unpressurized 
logistics  carriers  will  ease  the  pressure  for  on-line  ground 
processing  and  will  be  a compatible  addition  to  the  tasks 
already  performed  on  the  logistics  facility. 

Key  Areas  of  Concern 


Maintenance  Paradox.  In  the  process  of  reviewing  the  Work 
Package  RFPs,  the  Logistics  Subpanel  concluded  that  the 
requirements  for  reliability  and  maintainability  were  not 
consistently  applied  to  all  the  RFPs  and  that  the  criteria 
stated  was  extremely  ambitious.  The  subpanel  sought  to  examine 
the  maintenance  philosophy  and  to  compare  the  current  Space 
Station  approach  with  other  comparable  systems.  Figure  3-3 
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Figure  3-3.  Space  Station  Maintenance  Paradox 


displays  the  maintenance  man-hours  per  system  operating  hour  for 
the  systems  examined.  The  paradox  lies  in  the  fact  that 
maintenance  man-hours  per  system  operating  hour  decreases  as 
system  complexity  decreases,  yet  the  Space  Station  design  is 
very  complex  and  is  allotted  fewer  maintenance  man-hours  per 
system  operating  hour. 

In  achieving  the  0.001  maintenance  man-hours  per  system 
operating  hour  for  the  remote  radar  sites,  the  Air  Force  used  a 
number  of  techniques  to  focus  on  reliability  and 
maintainability  as  design  requirements.  Proposal  evaluation 
criteria,  requirements  to  demonstrate  reliability  during 
design,  award  fee  evaluation  criteria  and  performance  bonuses 
were  all  employed  to  get  the  contractor  to  focus  on  delivering 
a very  reliable  product  that  required  a minimum  of  maintenance. 

Another  aspect  of  the  paradox  which  needs  closer  examination  is 
the  trade-off  between  experiment  operations  and  on-orbit 
repair.  The  philosophy  followed  by  the  Air  Force  in  achieving 
the  low  maintenance  man-hour  posture  is  to  only  remove  and 
replace  failed  components.  Most  repair  is  done  at  a depot 
facility;  there  is  no  attempt  to  perform  major  repair  at  the 
remote  site.  There  are,  however,  combinations  of  circumstances 
for  which  it  is  economical  to  perform  repair  on-orbit.  Mr. 
Robert  Shiskho  of  JPL  points  out  in  a position  paper  written 
for  the  subpanel  that  the  key  decision  factors  are  the  "prices" 
one  associates  with  parameters  such  as  crewtime  and  delivery  to 
orbit.  The  issues  of  "real  cost",  imputed  cost  and  opportunity 
cost  need  to  be  addressed  as  applied  to  the  Space  Station 
maintenance  philosophy. 


A further  manifestation  of  the  subpanel's  concern  is  addressed 
by  David  Lowry,  Boeing  Aerospace  Company,  and  Thomas  Feaster, 
NASA  KSC,  in  their  Space  Congress  presentation  entitled,  " 
Regaining  Space  Leadership  Through  the  Control  of  Life  Cycle 
Cost”.  Their  discussion  points  out  that  the  Department  of 
Defense  and  commercial  aircraft  development  efforts  typically 
spend  forty  percent  of  the  life  cycle  cost  in  design, 
development  and  production  and  sixty  percent  in  operations. 
Whereas  in  the  Space  Shuttle  Program,  fourteen  percent  of  the 
life  cycle  cost  was  spent  in  design,  development  and  production 
and  eighty  six  percent  spent  in  operations.  Even  when  the 
subtleties  of  the  NASA  budget  process  are  accounted  for,  the 
message  is  clear:  the  energy  spent  during  design  on  behalf  of 
high  reliability  and  low  maintainability  pays  back  handsomely. 

The  Logistics  Subpanel  suggests  that  the  program  requirements 
for  reliability  and  maintainability  should  be  reviewed  for 
compatibility  with  the  state-of-the  art  in  system  design  and 
with  the  assumptions  concerning  the  cost  of  current  program 
design  requirements.  After  a position  has  been  established,  a 
clear,  concise  and  consistent  description  of  the  NASA  design 
expectation  should  be  provided  to  the  Work  Package  contractors. 
Consideration  should  also,  be  given  to  innovative  approaches  to 
encourage  the  contractors  to  enhance  the  reliability  and 
maintainability  of  their  designs. 

Resupply  Return.  The  current  state  of  resupply/ return 
planning  places  the  Space  Station  Program  in  great  peril.  The 
existing  projections  of  under  support  are  approximately  35,000 
pounds  a year  of  up  mass  and  150,000  pounds  a year  of  down 
mass.  Equally  as  disturbing  is  the  apparent  lack  of  assignment 
of  the  management  of  this  critical  aspect  of  the  program.  The 
management  of  resupply/ return  requirements  was  assigned  to  the 
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Integrated  Logistics  Working  Group(ILWG).  The  ILWG  has  since 
become  inactive,  not  having  met  since  August,  1986.  The 
management  of  resupply/ return  capability  development  appears 
not  to  be  organizationally  assigned.  The  subpanel  could  not 
find  a group  actively  pursuing  the  resolution  of  this 
operational  dilemma.  The  over  subscription  of  Space  Shuttle 
based  resupply /return  capability  and  the  degradation  in  Space 
Shuttle  availability  as  a transportation  medium  for  the  Space 
Station  call  for  an  aggressive  review  of  resupply/ return 
planning  and  management. 

The  Logistics  Subpanel  recommends  that  the  Integrated  Logistics 
Working  Group  be  revitalized  and  their  assignment  to  manage 
resupply /return  requirements  be  vigorously  pursued.  Further, 
that  the  Space  Station  Program  reassess  the  realities  of  the 
degrading  availability  of  Space  Shuttle  and  aggressively 
examine  all  expendable  launch  vehicle  alternatives  for 
accomplishing  resupply /return.  In  addition,  the  management  of 
resupply/ return  capability  development  should  be  clearly 
assigned  and  the  long  term  management  of  resupply/ return  should 
be  considered  for  delegation  to  the  LOC  to  facilitate  the 
synergistic  management  of  maintenance,  resupply/ return  and  the 
logistics  infrastructure  that  support  the  program. 

On-Orbit  Storage  - In  reviewing  the  allocations  of  on-orbit 
weight  and  volume  for  various  activities  (JSC  30000  Section  6, 
Rev.  A)  , the  Logistics  Subpanel  could  not  find  allocations  for 
on-orbit  storage.  The  requirements  document  calls  for  the 
incorporation  of  storage  in  the  element  designs  but  gives  no 
allocation  of  weight  or  volume.  All  of  the  schemes  for  the 
management  of  resupply /return  presented  to  the  Subpanel  called 
for  extensive  on-orbit  storage.  However,  there  is  no  apparent 
assignment  of  management  responsibility  for  this  critical  Space 
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Station  resource.  The  Logistics  Subpanel  recommends  that  this 
assignment  be  given  to  the  ILWG  as  a synergistic  addition  to 
their  resupply/ return  requirements  management  role. 

RFP  Inconsistencies  - Since  the  review  of  the  Work  Package 
RFP's  was  completed,  we  have  not,  as  a group,  had  the 
opportunity  to  look  at  the  revised  RFPs  to  ensure  the  fidelity 
of  data  items  and  data  item  delivery  schedules.  However,  the 
review  in  the  Fall  of  1986  revealed  inconsistencies  in 
across-the-board  data  requirements,  (see  Table  3-1)  a 
characteristic  that  will  compound  the  work  required  in 
integration  of  Work  Package  products.  The  attempt  to  create  a 
common  content  document  for  use  in  RFP  preparation  was  an 
excellent  step.  Unfortunately,  the  translation  of  the  common 
content  document  into  individual  RFP  requirements  was  not 
uniform.  As  a result  the  requirements  for  system  Availability, 
Reliability,  and  Maintainability  are  not  consistent  across  the 
Work  Packages.  The  long  term  cost  and  supportability  of  the 
integrated  Space  Station  will  be  heavily  dependent  on  the 
consistency  of  logistics  design  across  the  Work  Packages. 

The  subpanel  recommends  the  RFP's  be  reviewed  for  consistency 
of  data  and  design  requirements,  and  that  inconsistencies 
receive  appropriate  resolution  through  the  Program  Office 
action.  (See  Table  3-2). 

3.2.2  Assumptions 

These  assumptions  have  been  segregated  into  three  categories 
strategic,  tactical  and  execution.  This  segregation  is 
consistent  with  the  following  SSOTF  "criteria  for  assignment  of 
functions" : 
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TABLE  3-1  RFP  LOGISTICS  DATA  REQUIREMENTS 


RECOWENDATIONS  FOR  RFP  LOGISTICS  DATA  REQUIREMENTS 

1.  Require  initial  submission  with  proposal  (including  PSC) 

2.  Negotiate  NASA  comments  prior  to  contract  award 

3.  Require  revised  submission  30  days  after  CSD 

4.  Establish  minimum  program  wide  data  requirements  content 

5.  Develop  review  criteria  for  each  submission 

< 

6.  Centrally  approve  (Level  A')  the  RID  package  for  each  submission  (i.e.  the 
baseline  to  negotiate  comments  with  contractor) 

7.  Centrally  (A*)  verify  that  the  RID  package  has  been  negotiated  in  an  acceptable 
manner  prior  to  authorizing  contract  award 

8.  Provide  on-going  oversight  (A1)  of  plan  implementations 

TABLE  3-2  REVIEW  OF  DATA  AND  DESIGN  REQUIREMENTS 
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o Strategic  - Those  functions  concerned  primarily 
with  establishing  and  coordinating  the  objectives 
and  policies  of  the  organization.  These  objectives 
and  policies  affect  a broad  range  of  customers  and 
institutional  activities. 

o Tactical  - Those  functions  concerned  primarily  with 
using  the  established  objectives  and  policies  to 
produce  plans  and  directions  for  their 
accomplishment . 

o Execution  - Those  functions  whose  products  and 
activities  result  in  either  an  institutional  end 
product  or  products  and  activities  accomplishing 
the  details  of  a plan  in  support  of  a specific  end 
product . 

Strategic  Assumptions 

1.  By  2010  A.D.,  the  operational  phase  has  matured  to  the 
full  up  operational  station. 

2.  Growth/evolution  phase  is  now  in  process. 

3.  . Users  are  NASA,  U.S.  industry,  academic,  DoD, 

internationals  and  private  citizens. 

4.  NASA  provides  any  off-line  Space  Station  user  with 
support/ logistics  as  negotiated,  budgeted  and  funded 
by  the  user.  Support  is  provided  by  the  operations 
center  and  reimbursed  by  the  user. 

5.  NASA  is  still  an  integral  part  of  the 
management/execution  scheme. 

6.  Associate  Administrators  for  programs  still  exist  at 
NASA  Headquarters;  the  Associate  Administrator  for 
Space  Station  operations  is  located  at  Headquarters. 

7.  The  traditional  roles  for  NASA  centers  remain  the 
same.  KSC  has  become  the  agency's  focal  point  for 
space  operations.  There  are  operations  contractors 
for  both  the  STS  and  the  Space  Station,  and  new 
systems  are  expected  to  follow  suit. 

8.  New  starts  include  Space  Stations  2 and  3,  Mars 
Mission,  Lunar  Station  and  STS  II. 

9.  Industry  is  a "participant"  in  some  programs,  i.e.,  in 
partnership  with  NASA. 
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10.  Internationals  and  DOD  are  participants  on  Space 
Station. 

Tactical 

1.  The  prime  Space  Station  logistics  functions  are  ground 
and  on-orbit  maintenance  and  resupply /return. 

2.  The  Space  Station  Program  elements  include  two  U.S. 
modules,  four  nodes,  truss  structure,  co-orbiting  and 
polar  platforms,  photovoltaic  and  solar  dynamic  power 
systems,  a satellite  servicing  facility,  a mobile 
service  center,  two  international  modules,  and  five 
different  logistics  carrier  types.  These  systems  are 
comprised  of  state-of-the  art  space  qualified  hardware 
and  include  all  the  subsystems  necessary  to  sustain 
life  and  on-orbit  operations. 

3.  Three  maintenance  levels  have  been  implemented: 
organizational  (on-orbit  and  ground),  intermediate 
(ground  repair/modif ication)  and  depot  (modification, 
repair,  fabrication  and  checkout). 

4.  Organizationally,  "Logistics"  is  on  the  same  level  as 
"Operations"  and  "Systems,  Integration  and 
Engineering" . 

5.  A high  priority  small  sample  return  system  is 
operational,  e.g.,  parachute  recovery  by  a C-131, 
unmanned  recovery  capsule  or  remotely  piloted  vehicle. 
The  Crew  Emergency  Return  Vehicle  also  supports  this 
activity. 

6.  A Logistics  Operations  Center  (LOC)  manages  integrated 
logistics  support  for  the  Space  Station  Program. 

7.  The  Space  Station  inventory  management  system  is  a 
subset  of  the  Logistics  Information  System  and 
includes  the  management  of  assets  on  the  ground  and  on 
orbit. 

8.  On-Orbit  Replaceable  Onits  are  verified  operational  by 
operations  center  personnel  prior  to  shipment  to  the 
Space  Station. 

9.  The  resupply  interval  is  45  days. 

10.  Engineering  and  maintenance  technical  data  is  adequate 
for  inhouse  support  to  ground  and  on-orbit  Space 
Station  systems,  including  support  equipment. 
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11.  Integrated,  relational  data  base  products  are 
available  for  logistics  trend  analysis  and  corrective 
action. 

12.  The  Logistics  Operations  Center  has  implemented  a 
fully  automated  warehouse  which  utilizes  bar-coding 
and  other  "smart"  identification  tags. 

13.  Logistics  management  responsibility  transfer  (LMRT)  to 
the  Logistics  Operations  Center  was  initiated  during 
Phase  C/D  and  completed  on  a system-by-system  basis 
within  one  year  after  orbital  deployment. 

14.  Industry  still  exists  in  customer /contractor 
relationships  in  all  programs. 

15.  Medium  and  heavy  lift  expendable  launch  vehicles  are 
an  integral  part  of  space  transportation  services. 

16.  The  1990-2015  program  dilemma  associated  with  an 
inability  to  support  the  annual  up  mass  and  down  mass 
requirements  has  been  resolved.  The  management  of 
resupply /return  is  a primary  function  of  the  Logistics 
Operations  Center. 

17.  Crew  rescue  vehicles  are  part  of  the  U.S.  space 
transportation  services  fleet. 

18.  The  on-orbit  maintenance  concept  of  "Remove  and 
Replace  at  the  ORO/LRU  level"  was  designed  in  during 
Phase  C/D  and  has  been  proven. 

Execution 

1.  Source,  Maintenance  and  Recoverability  (SMR)  codes  are 
used  to  procure,  maintain,  and  dispose  of  material. 

2.  Spares  have  been  acquired  to  provide  the  best  system 
availability  for  the  optimum  funding  level. 

3.  Maintenance  - After  an  ORD  has  been  received  at  the 
repair  location  the  nominal  turn-around-time  (TAT)  for 
ORU  repair  is: 

o Intermediate  level  - 14  days 
o Depot  Level  at  the  LOC  - 30  days 
o Depot  level  within  the  U.S.  - 60  days, 
o Depot  level  outside  the  U.S.,  i.e.,  international  - 
90  days. 
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4.  Fly-in  maintenance  crews  augment  on-orbit  maintenance. 
The  fly-in  maintenance  crews  consist  of  normally 
ground-based  maintenance  personnel. 

5.  Material  Management 

o There  are  approximately  300,000  line  items  in  the 
Space  Station  inventory. 

o The  initial  provisioning  for  new  items  covers  24 
months  after  the  first  planned  use. 

o The  inventory  management  system  accommodates  the 
partner-participants . 

6.  Cannibalization  is  used  only  to  correct  an  on-orbit 
life-threatening  situation. 

7.  National  Stock  Numbers  for  all  parts  are  identified  by 
the  Federal  Supply  Code  for  manufacturers  and 
manufacturers ' part  number . 

8.  Average  Space  Station  ORO  characteristics: 

Weight:  16.1  pounds 

Size:  1.0  cubic  foot 

Cost:  $2 0k/ pound  installed  in  orbit 

Cost  base:  1986  dollars 

Cost  /ORO:  $322k 

10  SROs:  ORO 

20  piece  parts/SRO 

On-orbit  storage  requirements:  TBD 

9.  A nominal  cost  of  one  man  year's  effort  (50K  per  year, 
84  $)  is  needed  to  keep  an  OEM's  door  open.  This 
amount  is  considered  an  overhead  tax  for  a plant 
contact,  updated  drawings,  operational  test  equipment, 
etc.  This  cost  does  not  include  any  actual  repair 
costs. 

10.  An  economic  discard  criteria  of  spending  no  more  than 
65%  of  replacement  cost  of  an  ORO  is  the  guide  for 


3-23 


repair /discard.  Discard  by  orbital  deboost  and 
reentry  burn  is  an  option  applied  when  return  capacity 
is  exceeded,  on-orbit  stowage  capacity  is  maxed  out 
and  non-toxic  burn  products  result. 

11.  Serialized  control  for  all  ORUs  permits  precise 
configuration  control  and  "bad  actor"  corrective 
action. 

12.  The  Viking  Lunar  Lander  Oven  at  KSC  is  available  for 
refurbishment  and  reuse  for  Space  Station;  ORU 
recertification  and  additional  facilities  for 
vibration  and  thermal -vacuum  testing  have  been  added. 

Anticipated  New  Technology  and  Innovations. 


The  following  technology  enhancements  have  been  assumed  as 
applicable  to  the  logistics  support  efforts  in  the  year  2010. 


CAD/CAM/CAE  Interface  with  LIS 


1.  Computer  aided  design  is  routine 

2.  Logistics  information  system  interfaces  with  the 
CAD/CAE  data  bases  provide  a CALS  capability. 

3.  Repair  procedures  are  automated  with  touch  screen  and 
voice  recognition  features. 

Artificial  Intelligence  (AI) 

1.  Artificial  intelligence  is  in  the  process  of  maturing. 

2.  Breakthroughs  have  occurred  which  aid  in  applying  this 
technology  to  repair  diagnostics. 

Machine  Vision  (MV) 

1.  Machine  vision  is  an  extension  of  AI. 

2.  Optomechanical  sensors  substitute  for  human  optical  and 
tactile  sensors. 
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Automatic  Fault  Isolation  and  Self  Healing 


1.  AI  and  MV  augment  failure  identification. 

2.  Self  repair  is  automated  to  a low  level  of  capability 

3.2.3  Major  Functiona 


3. 2. 3.1  Maintenance  - Maintenance  is  a primary  task  for  the 
operational  Space  Station  logistics  system.  The  scope  of 
activities  involved  and  the  breadth  of  interfaces  necessary  to 
integrate  maintenance  activities  with  other  activities  led  the 
panel  to  address  a structure  for  maintenance  management.  Table 
3-3  shows  the  interfaces  for  on-orbit  and  ground  maintenance. 
Historically  the  management  of  these  program  elements  has  been 
fragmented  and  distributed  across  several  Centers.  In  order  to 
support  the  strategic  and  tactical  planning  process  and  to 
effectively  execute  on-orbit  maintenance,  these  program 
elements  must  be  managed  in  a different  fashion. 

Figure  3-4  addresses  the  complexity  associated  with  the 
resolution  of  resupply /return  requirements  and  the  management 
fragmentation  of  the  resources  necessary  to  satisfy  those 
requirements.  The  resolution  of  requirements  priorities  is 
clearly  a strategic/tactical  task  which  must  be  accomplished  in 
the  rarefied  environment  of  the  Tactical  Operations  Control 
Board  ( TOCB ) . 

The  management  structure  necessary  to  ensure  the  effective  and 
efficient  management  of  Space  Station  Maintenance  and 
resupply/ return  must  cope  with  the  diversity  of  integration  and 
management  interfaces.  It  must  be  capable  of  integrating 
strategic,  tactical  and  execution  level  of  planning.  It  must 
identify  accountability  for  Space  Station  performance  and  it 
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TABLE  3-3 


MAINTENANCE  ELEMENT  INTERFACES 

ON  ORBIT  INTERFACES 

SUSTAINING  ENGINEERING 

CONFIGURATION  MANAGEMENT 
MODIFICATION  MANAGEMENT 

LOGISTICS 

INVENTORY  MANAGEMENT 

REPAIR  MANAGEMENT 

STORAGE  MANAGEMENT 

TECHNICAL  DOCUMENTATION  MANAGEMENT 

ON-ORBIT  OPERATIONS 

ON-ORBIT  CONFIGURATION  MANAGEMENT 
CREW  ACTIVITY  PLANNING 

GROUND  INTERFACES 

DISTRIBUTED  GSE/ATE/ INTEGRATION  FACILITIES 
SYSTEMS  WITH  INSTITUTIONAL  IDENTITY 
WAREHOUSING 
SIMULATORS 
TRAINERS 
TEST  BEDS 

PROGRAM  AND  INSTITUTIONAL  FUNDING 
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o Requirements  resolution  is  a strategic/tactical  task, 
o Resource  management  is  fragmented 

o Payload  capacity  to  and  from  orbit  is  oversubscribed 


- Training  - Tech  DOC  - STS  Spares 

- Availability  - Procedures  - ELV  (OS)  Tools 

. “ Trends  - ELV  (Non-OS)  Test  Equip 

Consumables 

Products 


FIGURE  3-4  RESUPPLY /RETURN 
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must  manage  the  systemic  processes  and  issues  which  cross 
institutional  and  management  level  boundaries*  The  Head- 
quarters and  operations  center  structure  proposed  is  shown  in 
Figure  3-5.  The  Program  Office  would  provide  the  strategic  and 
tactical  integration  across  requirements  and  integrate  the 
planning  requirements  across  ground,  logistics,  and  on-orbit 
operations.  The  Logistics  Operations  Center,  located  at  the 
ground  operations  center,  would  provide  the  day-to-day 
management  of  Space  Station  logistics  support.  It  would  provide 
technical  logistics  support  to  the  TOCB  process  and  would 
manage  Maintenance  both  on-orbit  and  on  the  ground  and 
resupply /return. 

The  management  roles  are  shown  in  Table  3—4  and  Table  3-5. 

The  establishment  of  the ^dedicated  Headquarters  logistics 
function  and  the  Logistics  Operations  Center  will  provide  the 
continuity  of  strategic,  tactical,  and  execution  logistics 
planning  and  actual  execution  necessary  for  effective  Logistics 
support  to  the  program. 

ON-ORBIT  MAINTENANCE 

The  successful  planning  and  execution  of  on-orbit  maintenance 
for  the  Space  Station  will  be  one  of  the  most  challenging 
operations  era  tasks.  The  synthesis  of  flight  increment  (see 
discussion  under  Anticipated  Environment)  maintenance  and 
modification  plans  and  their  integration  into  the  strategic, 
tactical  and  execution  planning  process  will  require  the 
integration  of  Sustaining  Engineering  technical  documentation, 
material/tools/training,  repair  management,  and  resupply/ return 
management  requirements  with  the  operational  constraints 
imposed  by  the  Space  Station  Support  Center  and  Payload 
Operations  Integration  Center.  The  following  discussion 
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Figure  3-5.  Headquarters  and  Operations  Center  Organizational  Structure 


TABLE  3-4 


PROGRAM  OFFICE  LOGISTICS  MANAGEMENT  ROLES 


o ESTABLISHES  AND  MAINTAINS  SPACE  STATION  PROGRAM 
LOGISTICS  POLICY  PROCEDURES , SPECIFICATIONS , AND 
STANDARDS 


o REPORTS  DIRECTLY  TO  SS  OPERATIONS  FOR  SS  PERFORMANCE 


o INTEGRATES  TOCB  DECISIONS  INTO  GROUND,  LOGISTICS  AND 
ON-ORBIT  TACTICAL/EXECUTION  PLANNING  REQUIREMENTS. 


o GENERATES  LOGISTICS,  GROUND  AND  ON-ORBIT  STRATEGIC 
PLANS 


o APPROVES  LOGISTICS  GROUND,  AND  ON-ORBIT  TACTICAL  AND 
EXECUTION  PLANS 


O MANAGES  RESUPPLY/RETURN 


o MANAGES  ON-ORBIT  AND  GROUND  MAINTENANCE 


o MANAGES  BUDGET  FOR  SPACE  STATION  PROGRAM  LOGISTICS 
ACTIVITIES 


O INVOLVES  CENTER  PERSONNEL  THROUGH  TDY  ASSIGNMENTS 


O PROVIDES  PERFORMANCE  APPRAISAL  INPUTS  FOR  LOGISTICS, 
GROUND,  AND  ON-ORBIT  OPERATIONS  MANAGERS 
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TABLE  3-5 


LOGISTICS  OPERATIONS  CENTER  MANAGEMENT  ROLES 


o DEVELOPS  STRATEGIC  PLANNING  INPUTS  FOR  THE  PROGRAM 
OFFICE 


o DEVELOPS  TACTICAL  AND  EXECUTION  LOGISTICS  PLANS  FOR 
GROUND  AND  ON-ORBIT  SUPPORT 


O EXECUTES  RESUPPLY/RETURN  FUNCTION 


o EXECUTES  MAINTENANCE , REPLENISHMENT  AND  USER  LOGISTICS 
SUPPORT  FUNCTIONS 


o MANAGES  LOGISTICS  OPERATIONS  AT  THE  OPERATIONS  CENTER 


O MANAGES  THE  LOGISTICS  INFORMATION  SYSTEM 


o MANAGES  BUDGET  FOR  ASSIGNED  HARDWARE , SOFTWARE  AND 
CONSUMABLES 


o MONITORS /MANAGES  REPAIR  CYCLES  FOR  GSE,  ORU'S,  ATE  AND 
SRU'S 


o MONITORS  TRANSPORTATION  STATUS  AND  CHANGES  SHIPPING 
PRIORITIES 
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addresses  the  proposed  approach  to  on-orbit  maintenance  plan- 
ning, the  operational  environment  expected  and  a description  of 
on-orbit  maintenance  execution. 

Strategic  Planning  Concept 

The  Logistics  Operations  Center  (LOC)  provides  technical  input 
to  the  Space  Station  Users  Board  (SSUB)  in  support  of  the 
development  of  the  five  year  Consolidated  Utilization  Plan 
(CUP).  The  LOC  annually  provides  the  SSUB  with  a strategic 
(24-60  month)  maintenance  and  modification  requirement 
projection.  Tactical  planning  approval  status  is  shown  on  this 
projection  for  maintenance  and  modification  requirements  in  the 
twenty-four  (24)  to  thirty-six  (36)  month  time  frame.  Tactical 
planning  approval  prerequisites  and,  where  applicable, 
resupply /return  and  evolution  mass  and  volume  requirements  are 
identified  in  the  projection. 

The  SSUB  integrates  the  LOC  strategic  planning  requirements 
with  the  strategic  planning  input  received  from  the  SSSC,  POIC 
and  the  ground  operations  center.  This  strategic  projection 
identifies  the  gross  man-hour,  mass  and  volume  requirements  of 
each  flight  increment.  The  SSUB  integrates  the  inputs  received 
to  prepare  the  CUP.  This  integration  process  verifies  that  all 
proposed  events  comply  with  strategic  planning  prerequisites; 
program  man-hour,  mass  and  volume  units  are  not  exceeded;  and 
event  priorities  are  established.  An  approved  budget  and  an 
acceptable  procurement  schedule,  if  applicable,  are  minimum 
strategic  planning  approval  prerequisites.  Thus,  the  strategic 
planning  process  represents  the  allocation  of  critical  orbital 
resources  (man-hours,  mass  and  volume)  in  a prioritized  manner 
which  identifies  the  impact  of  the  decisions  made  and  affords 
an  opportunity  to  explore  alternatives. 
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Tactical  Planning  Concept 


Semiannually,  the  Space  Station  Tactical  Operations  Control 
Board  (TOCB)  issues  a Space  Station  Tactical  Operations  Plan 
(TOP).  This  plan  addresses  the  major  events  scheduled  for 
accomplishment  during  each  flight  increment  in  the  next  twelve 
(12)  to  thirty-six  (36)  months.  Thus,  the  TOP  includes  the 
tactical  planning  window  (18-36  month  time  frame)  and  overlaps 
the  execution  planning  window. 

The  TOP  establishes  a man-hour  allocation  for  the  major  events 
in  each  flight  increment.  Each  man-hour  allocation  is 
segregated  into  an  IVA  and  EVA  component.  In  addition  to  an 
event  man-hour  allocation,  the  TOP  establishes  an  event  mass  and 
volume  allocation  for  the  resupply /return.  The  TOP  includes  a 
major  sequence  profile  for  each  flight  increment.  The  man-hour 
requirements  for  each  event  are  identified  on  the  event 
sequence  profile.  The  resupply  and  return  profiles  also 
identify  applicable  mass  and  volume  requirements.  In  addition, 
the  event  sequence  profiles  cite  Space  Station  Execution 
Operations  Plan  (EOP)  event  approval  prerequisites.  The  TOP 
shows  the  EOP  approval  status  of  events  and  event  sequence 
profiles  in  each  flight  increment  in  the  next  twenty-four  (24) 
to  thirty-six  (36)  months. 

The  LOC  semiannually  provides  the  TOCB  a tactical  (18-36  month) 
maintenance  and  modification  event  sequence  profile.  Execution 
planning  approval  status  is  shown  on  this  profile  for 
maintenance  and  modification  requirements  in  the  next  twelve 
(12)  to  eighteen  (18)  months.  Execution  planning  approval 
prerequisites,  and  where  applicable,  resupply/ return  mass  and 
volume  requirements  are  also  identified  in  the  profiles. 
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The  TOCB  integrates  the  input  received  from  the  LOC  with  inputs 
received  from  the  SSSC,  the  POIC  and  the  Operations  Center  to 
prepare  the  TOP.  This  integration  process  verifies  that  all 
proposed  profiles  comply  with  tactical  planning  prerequisites; 
event  man-hour , mass  and  volume  limits  are  not  exceeded;  and 
event  priorities  are  reconciled.  Identification  of  payload 
integration  requirements,  definition  of  the  on-orbit  event 
execution  steps  and  associated  man-hour  requirements,  hardware 
delivery  schedules  consistent  with  payload  integration 
requirements,  and  the  delivery  of  on-orbit  event  execution 
procedures  are  typical  execution  planning  approval 
prerequisites.  Thus,  the  tactical  planning  process  represents 
a prioritization  of  critical  orbital  resources  (man-hours,  mass 
and  volume)  and  a verification  of  execution  planning 
prerequisites  in  a manner  which  identifies  the  impact  of  the 
decisions  made  and  affords  an  opportunity  to  explore 
alternatives. 

Execution  Planning  Concept 

Quarterly,  the  TOCB  issues  a Space  Station  Execution  Operations 
Plan  (EOP).  This  plan  addresses  all  events  scheduled  for 
accomplishment  during  each  Transfer  Period  and  Flight  Segment 
in  the  next  eighteen  (18)  months.  Thus,  the  EOP  includes  the 
execution  planning  window  and  overlaps  the  current  execution 
period  (0-3  month  time  frame). 

The  LOC  forwards  maintenance  and  modification  execution  event 
planning  and  verification  data  to  the  TOCB  quarterly.  This 
data  shows  execution  event  verification  status  for  maintenance 
and  modification  requirements  in  the  next  three  (3)  to  eighteen 
(18)  months.  Execution  event  verification  is  a mandatory 
execution  event  approval  prerequisite. 
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The  TOCB  integrates  the  LOC,  SSSC,  POIC  execution  event  data 
with  data  received  from  the  Operations  Center.  After  all  data 
is  integrated,  the  TOCB  issues  the  EOP.  The  EOP  shows  the 
actual  execution  approval  status  of  each  planned  execution 
event.  Thus,  the  execution  planning  process  represents  a 
gateway  through  which  an  event  must  pass  to  verify  that  the 
event  can  be  safely  accomplished  on-orbit  and  to  accommodate 
priority  realignments. 

ANTICIPATED  ENVIRONMENT  (2010  AD) 

Space  Station  operations  are  executed  in  a series  of  repetitive 
45  day  cycles  throughout  the  useful  life  of  the  Space  Station. 
Each  45  day  cycle  is  composed  of  three  segments.  One  segment 
is  a 7-10  day  transfer  period  during  which  the  Space  Shuttle  or 
other  carrier /vehicle  is  docked  at  the  Space  Station.  The 
second  segment  is  a 22-25  day  operations  and  maintenance 
segment  during  which  the  Space  Shuttle  is  not  docked  at  the 
Space  Station.  The  third  segment  is  a 7-10  day  period  in 
preparation  for  return  of  the  Space  Shuttle. 

The  Space  Station  is  in  mature  operations.  Major  reliability 
problems  have  been  solved.  Design  modifications  have  been 
installed  to  reduce  the  on-orbit  maintenance  workload 
experienced  during  the  early  operational  years.  Validated  data 
bases  exist  to  justify  all  on-orbit  "in-place"  consumable 
replenishments/replacements  which  are  minimal. 

On-orbit  "Repair-in-Place"  and  "Repair  Off-Line"  maintenance 
actions  are  performed  only  in  response  to  safety  related 
emergency  conditions.  On-orbit  maintenance  of  Space  Station 
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Elements /Systems /Equipment  consists  of  one  or  more  of  the  four 
following  types  of  maintenance:  1)  Periodic  maintenance 

(preventive),  2)  Condition-Monitored  Maintenance  (preventive), 
3)  On-Condition  Maintenance  (corrective),  and  4) 
modification.  These  terms  are  defined  below. 

a.  Preventive  Maintenance 

Periodic  Maintenance:  The  replacement  of  an  item  with  an 

identical  item  on  a fixed  schedule.  The  fixed  schedule  is 
based  on  validated  historical  data.  This  type  of  maintenance 
is  required  for  mission  critical  and  safety  items  and  is 
scheduled  for  accomplishment  during  transfer  periods. 

Condition  Monitored  Maintenance:  The  replacement  of  an  item 

with  an  identical  item  on  a schedule  determined  by  the 
continuous  analysis  of  operational  performance  data.  This  type 
of  maintenance  is  required  for  safety  items  and  highly 
desirable  for  mission  items  as  well  as  other  items. 

Maintenance  is  scheduled  for  accomplishment  during  flight 
increments . 

b.  Corrective  Maintenance 

On-Condition  Maintenance:  The  unscheduled  replacement  of  an 

item,  after  failure,  with  an  identical  item.  This  type  of 
maintenance  is  not  applicable  to  safety  nor  mission  critical 
items.  On-Condition  maintenance  can  be  scheduled  for 
accomplishment  during  either  the  transfer  periods  or  flight 
increments . 

c.  Modification:  The  scheduled  replacement  of  an  item  with  an 

item  of  a different  configuration  (new  or  modified).  This  type 
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of  maintenance  is  scheduled  for  accomplishment  during  transfer 
period  for  mission  and  safety  items.  Modification  to  other 
items  are  scheduled  for  accomplishment  during  transfer 
periods. 

Due  to  1)  the  availability  of  additional  manpower,  2)  the 
reduction  of  an  on-orbit  storage  requirement,  3)  the 
elimination  of  the  risk  of  installing  spares  of  the  wrong 
configuration,  and  4)  the  impact  on  flight  increment 
operations,  modernizations  are  normally  made  and  tested  during 
transfer  periods  instead  of  flight  increments. 

ON-ORBIT  EXECUTION  DESCRIPTION 

On-orbit  maintenance  execution  for  Space  Station  hardware 
requires  the  existence  of  logistics  systems,  organizations,  and 
capabilities  along  with  compatible  Space  Station  hardware.  The 
systems,  facilities  and  capabilities  cannot  be  acquired  without 
a detailed  baseline  on-orbit  maintenance  scenario.  The 
following  discussion  provides  an  example  to  a level  of  detail 
required  to  support  acquisition  of  the  logistics  systems, 
organizations  and  capabilities. 

The  SSSC  transmits  a 10-day  on-orbit  event  schedule  to  the 
Space  Station  daily.  The  event  schedule  includes  all 
operations  and  maintenance  events  authorized  for  accomplishment 
during  the  10-day  period.  The  Space  Station  crew  can  adjust 
when  an  event  is  performed,  but  they  cannot  add  an  event  to  the 
schedule  i.e.,  all  events  must  be  entered  on  the  event  schedule 
by  the  SSSC.  The  SSSC  acts  as  the  single  point  of  contact  with 
the  Space  Station  for  all  matters  related  to  the  planning, 
scheduling  and  execution  of  emergency  corrective  maintenance. 
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The  SSSC  maintains  an  on-orbit  event  completion  file  and  an 
on-orbit  event  deferral  file.  Maintenance  event  completion  and 
deferral  information  is  transmitted  to  the  LOC  by  the  SSSC. 

The  LOC  updates  the  appropriate  LOC  files  to  reflect  this 
completion  and  deferral  information. 

The  LOC  identifies  the  on-orbit  manpower,  skills,  material  and 
technical  information  needed  to  perform  each  maintenance 
requirement  on  a transfer  period  or  flight  increment  and 
forwards  the  resulting  maintenance  list  to  SSSC.  The  LOC 
identifies  material  needed  to  accomplish  on-orbit  transfer 
period  or  flight  increment  maintenance  requirements  or  to 
replenish  material  used  during  previously  completed  on-orbit 
maintenance  events  and  relays  this  in  formation  into  the 
inventory  management  system.  The  inventory  management  system 
then  provides  the  manifest  status  of  this  material  to  the  LOC. 
The  LOC  adjusts  the  maintenance  requirement  schedule  to  reflect 
material  shortfalls  or  requests  a Space  Transportation  System 
manifest  priority  adjustment.  Resulting  maintenance  schedule 
revisions  are  forwarded  to  the  SSSC,  after  manifest  approval. 
The  master  orbital  hardware  maintenance  requirements  file  is 
linked  to  a configuration  status  accounting  file,  an  on-orbit 
maintenance  procedure  file,  an  on-orbit  inventory  management 
file,  a ground  inventory  management  file,  a modification 
requirements  file,  and  a maintenance  history  file.  The 
maintenance  history  file  includes  on-orbit  maintenance  event 
completion,  material  usage,  manpower  utilization,  procedure 
utilization,  maintenance  event  deferral  and  maintenance  event 
deferral  reason  information. 

The  LOC  coordinates  the  maintenance  of  an  on-orbit  data  file 
which  contains  the  procedures  needed  to  accomplish  the 
maintenance  requirements  on  the  flight  increment  schedules. 
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The  LOC  also  coordinates  the  maintenance  of  an  on-orbit  data 
file  which  contains  the  operating  and  casualty  procedures  used 
by  the  Space  Station  crew.  To  support  procedures  files 
maintenance,  the  LOC  coordinates  the  development , verification 
and/or  routine  transmission  of  maintenance  procedures  needed  to 
support  on-orbit  emergency  corrective  maintenance. 

The  LOC's  on-orbit  flight  increment  maintenance  requirements 
file  has  two  sections.  One  section,  the  Active  Maintenance 
section,  contains  all  maintenance  requirements  included  on  the 
10-day  operations  and  maintenance  event  schedule  issued  by  the 
SSSC  and  is  accessed  by  either  event  number  or  maintenance 
requirement  number.  The  second  section,  the  Maintenance 
Backlog  section,  contains  all  maintenance  requirements  for  the 
next  120  days  which  have  not  been  assigned  an  event  number  by 
the  SSSC,  and  it  is  accessed  by  date  or  maintenance  requirement 
number . 

A planning  and  estimating  (P&E)  record  exists  for  each 
maintenance  requirements  file*  This  P&E  record  contains  the 
major  steps  to  accomplish  each  maintenance  requirement,  the 
manpower  and  skill  level,  the  tools  and  test  equipment,  the 
material  and  the  maintenance  procedure  number (s)  needed  to 
perform  each  step. 

This  file  is  replicated  on-orbit.  The  LOC  transmits  weekly 
additions,  deletions  and  changes  to  the  maintenance  backlog 
section  of  this  file.  The  LOC  does  not  change  data  in  the 
Active  Maintenance  section  of  this  file.  The  Space  Station 
crew,  alone,  changes  data  in  the  Active  Maintenance  section  of 
this  file  to  show  that  a maintenance  requirement  is  either 
completed  or  deferred.  The  LOC  identifies  any  recommended 
changes  to  the  Active  Job  section  of  this  file  to  the  SSSC 
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which  in  turn  transmits  the  recommendations  to  the  Space 
Station  crew. 

In  developing  the  P&E  record  for  each  maintenance  requirement, 
the  LOC  verifies  the  on-orbit  availability  of  the  skill  level, 
material  (tools,  parts  and  test  equipment)  and  technical  data 
(maintenance  procedures  and  drawings).  Skill  level  shortfalls 
are  treated  as  replacement  crew  training  requirements . 

Material  shortfalls  are  treated  as  transportation  manifest  and 
inventory  management  system  demands,  and  technical  data 
shortfalls  are  treated  as  TMIS  development  requirements. 

Once  a maintenance  requirement  appears  on  the  10-day  on-orbit 
event  schedule,  the  Space  Station  crew  uses  the  P&E  record  to 
query  the  on-orbit  inventory  management  system  to  determine  the 
on-orbit  location  of  the  tools,  parts  and  test  equipment  needed 
to  accomplish  the  maintenance  requirement.  Thi.s  location  data 
is  copied  onto  the  P&E  record.  Similarly  the  Space  Station 
crew  queries  TMIS  and  copies  the  needed  maintenance  procedure 
as  a trailer  record  to  the  appropriate  step  in  the  P&E  record. 
These  copy  transaction  are  voice  activated  and/or  key  stroked. 
Any  material  or  technical  data  deficiency  is  communicated  to 
the  SSSC.  The  SSSC  coordinates  resolution  of  these 
deficiencies  with  the  LOC. 

The  P&E  record  and  the  technical  data  trailer  record  are 
down-loaded  onto  a portable  maintenance  aiding  device.  This 
maintenance  aiding  device  has,  for  example,  an  optical  scanner, 
a microphone,  a key  pad  and  a video  display.  The  Space  Station 
crew  obtains  the  material  needed  to  perform  the  maintenance 
event  from  its  on-orbit  storage  location. 

Using  the  optical  scanner,  the  crew  member  scans  the  material 
removed  and  its  storage  container.  If  the  item  scanned  is  not 
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on  the  P&E  record,  a suitable  response  is  provided  to  the  crew 
member . 

The  validated  material  is  then  taken  to  the  area  where  the 
maintenance  event  will  be  performed.  Since  the  on-orbit 
material  storage  location  is  close  to  the  on-orbit  location  of 
the  equipment  the  material  supports,  the  time  required  to 
transport  this  material  is  minimal . Using  the  maintenance 
aiding  device  for  procedural  guidance,  the  installed  material 
is  isolated  and  removed,  the  replacement  material  is  installed, 
and  a functional  test  is  performed.  Procedural  deviations  are 
voice  or  key  pad  entered  into  the  maintenance  aid  device.  The 
removed  material  is  scanned  and  placed  in  the  return  mass 
container  identified  on  the  P&E  record.  The  scanner  is  used  to 
read  the  bar  code  or  other  label  on  the  container  and  thereby 
identify  the  on-orbit  disposition  of  the  removed  material . 

The  crew  member  transfers  the  information  on  the  maintenance 
aiding  device  to  a maintenance  event  completion  record  in  an 
on-orbit  operations  and  maintenance  event  completion  file. 

This  record  is  transmitted  to  the  SSSC.  The  SSSC  closes  the 
maintenance  event  and  transmits  the  maintenance  event 
completion  record  to  the  LOC. 

If  the  maintenance  event  involves  installing  a modification 
(configuration  change),  the  P&E  record  for  the  maintenance 
event  will  include  steps  which:  1)  remove  obsolete  material 

(parts,  tools,  and  test  equipment)  and  put  them  in  down  mass 
containers,  2)  place  new  material  in  the  designated  on-orbit 
locations,  and  3)  purge  obsolete  and  add  new  maintenance 
procedures  to  on-orbit  technical  data  files. 
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GROUND  MAINTENANCE 


INTRODUCTION 

A number  of  issues  were  examined  by  the  panel  related  to  the 
maintenance  task  to  be  accomplished  on  the  ground.  The  trade 
off  between  original  equipment  manufacturer  (OEM)  support 
versus  the  role  of  a depot  repair  facility  in  the  repair  of 
on-orbit  hardware,  the  operational  dependence  of  the  Space 
Station  Program  on  systems  historically  viewed  as  institutional 
assets,  the  wide  distribution  of  GSE  that  will  require  repair 
support  and  the  relationship  between  repair  management  and 
resupply /return  management  were  the  major  subjects  addressed. 

REPAIR  OF  FLIGHT  HARDWARE 

The  repair  of  failed  flight  hardware  will  represent  a 
significant  portion  of  the  ground  maintenance  effort. 

Logistics  Support  Analysis  (LSA)  during  the  Phase  C/D  design 
effort  should  provide  a detailed  repair  level  analysis.  The 
planned  mix  of  repair  among  OEMs,  third  parties  and  on-site 
capability  should  be  examined.  The  analysis  of  probable  losses 
of  OEM  repair  capability  should  also  be  part  of  this  analysis 
and  a plan  to  recover  from  or  prevent  these  losses  should  be 
identified.  The  continued  use  of  the  development  prime 
contractor  as  an  agent  for  this  repair  in  all  likelihood  will 
be  prohibitively  expensive  as  has  been  demonstrated  by  the 
Space  Shuttle  program.  In  addition  to  the  development 
contractor  overhead  as  a cost  burden,  the  long  term  support 
from  the  original  equipment  manufacturer  is  an  expensive 
proposition  as  well.  The  maintenance  of  a repair  capability 
for  items  no  longer  manufactured  is  also  very  costly. 

In  a recent  study  of  Orbiter  hardware  it  was  estimated  to  cost 
S16-17M  to  keep  the  doors  open  for  three  years  at  seventeen 
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Orbiter  suppliers,  or  approximately  $300,000  per  year  per 
supplier.  It  is  estimated  that  approximately  three  hundred 
suppliers  of  Orbiter  hardware  may  have  to  be  supported  in  this 
fashion. The  current  estimate  of  Space  Station  Orbital 
Replaceable  Units  (ORU's)  is  four  to  five  thousand  units.  This 
estimate  includes  provision  for  all  four  Work  Packages.  For 
comparison  purposes  the  Space  Shuttle  Orbiter  has  approximately 
3800  Line  Replaceable  Units  (LRUs)  and  the  KSC  Launch 
Processing  System  (LPS)  has  approximately  3500  LRUs.  If  the 
Space  Station  experience  were  to  be  comparable  with  that  of  the 
Space  Shuttle  in  this  regard,  approximately  $100M  a year  would 
be  spent  to  just  keep  repair  capability  available  at  the  OEMS. 
The  results  of  the  Space  Shuttle  program  study  point  to  the 
need  for  an  on-or-near  site  depot  repair  facility  to  provide 
repair  support  at  a reasonable  cost. 

In  his  discussion  paper  to  the  SSOTF,  Mr.  Lorenz  Simpkins  of 
KSC  recommends: 

"...Specify  and  purchase  all  documentation. . .Plan  for 
the  assumption  of  the  maintenance  of  the  system  - use 
OEM  until  you  have  established  an  in-house 
capability .. .Develop  test  systems  with  both  Automated 
Test  Equipment  (ATE)  and  Artificial  Intelligence  (AI) 
concepts  in  order  to  capture  knowledge/expertise..." 

In  its  1986  annual  report  the  Aerospace  Safety  Advisory  Panel 
recommended  the  following  to  the  Space  Shuttle  program: 

”3. Establish  control  of  the  pipeline  for  the  repair  of 
Line  Replaceable  Units  (LRUs),  in  particular,  as  well 
as  for  other  components.  This  will  probably  include  the 
need  for  a repair  depot  on-site  at  KSC.  Although  it 
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will  be  necessary  to  return  certain  sensitive  units  to 
the  manufacturer  for  repair,  the  number  of  such  units 
should  be  kept  to  a minimum." 

The  Logistics  Subpanel  recommends  that  the  Space  Station 
Program  locate  a depot  level  repair  facility  with 
state-of-the-art  Automated  Test  Equipment  (ATE)  on-or-near  site 
at  the  ground  operations  center  under  the  management  direction 
of  the  Logistics  Operations  Center.  The  payback  in  reduced 
repair  cost  over  the  life  of  the  program  and  the  availability 
of  repair  capability  for  a thirty-year  period  will  more  than 
offset  the  initial  investment.  In  addition  to  the  repair 
function,  the  Space  Station  Program  will  require  the 
recertification  of  repaired  ORUs  prior  to  their  return  to 
orbit.  The  same  automated  test  equipment  and  software  used  to 
perform  failure  analysis  in  the  repair  process  can  be  used  to 
recertify  ORD  performance  prior  to  return  to  orbit.  The 
addition  environmental  retesting  required  should  also  be 
considered  as  a task  for  the  repair  facility. 

The  management  and  process  control  and  tracking  of  the  repair 
process  and  the  gathering  of  maintenance  trend  data  should  be 
automated  and  incorporated  as  part  of  the  Logistics  Information 
System. 

To  support  this  depot  repair  capability,  it  will  be  essential 
to  acquire  a complete  technical  data  package  during  the 
Phase  C/D  acquisition.  Every  person  involved  in  repair  and 
maintenance  management  who  made  input  to  the  SSOTF  strongly 
advised  the  purchase  of  technical  data,  repair  and  maintenance 
manuals  and  the  drawings  necessary  to  enable  reprocurement  as 
part  of  the  original  acquisition  effort.  The  acquisition  of 
these  technical  data  after  hardware  delivery  has  proven  to  be 
extremely  expensive.  The  current  estimate  to  acquire  the 
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necessary  technical  data  and  maintenance  manuals  for  Space 
Shuttle  Orbiter  support  is  $23M. 

The  development  of  execution  level  resupply /return  plans  for 
each  Space  Station  operations  increment  will  require  the 
integration  of  material  acquisition , on-orbit  maintenance 
requirements,  repair  management  and  logistics  carrier 
processing.  The  inclusion  of  repair  management  in  the 
responsibilities  of  the  LOC  is  essential  to  provide  close 
integration  of  repair  performance  with  resupply/return 
requirements  and  provide  the  necessary  interface  for  repair  and 
maintenance  management. 

The  timing  of  the  transfer  of  the  responsibility  for  repair  and 
maintenance  management  has  been  a subject  of  great  debate.  The 
Work  Package  requests  for  proposals  assigned  this  role  to  the 
development  contractor  through  IOC,  IOC  being  defined  as  after 
the  successful  launch  and  deployment  of  the  platforms.  In  the 
view  of  the  Logistics  Subpanel,  there  is  no  merit  in  leaving 
this  responsibility  with  the  development  contractor  for  ten 
years  after  the  hardware  has  been  deployed  in  orbit  which  the 
current  plan  would  call  for.  The  more  effective  approach  to  a 
timely  transition  of  management  roles  is  to  integrate  the 
acquisition  logistics  task  with  the  operational  logistics 
planning  and  capability  development.  By  involving  the  ultimate 
operator  in  the  Phase  C/D  activities,  a positive  logistics 
presence  will  be  felt  during  design  by  putting  the  "loggie 
elbows  on  the  drawing  board."  At  the  same  time,  the  capability 
to  provide  operational  logistics  capability  is  not  developed  in 
a vacuum  but  with  a real  time  awareness  of  the  design  process. 
Through  the  use  of  the  Program  Office  for  this  logistics 
integration  function,  the  capability  to  repair  and  maintain 
ORUs  would  be  in  place  at  the  time  the  hardware  is  assembled 
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and  verified,  and  the  management  responsibility  transfer  could 
be  easily  accomplished  within  a year  of  on-orbit  deployment. 

MAINTENANCE  OF  INSTITUTIONAL  SYSTEMS 

Historically,  institutional  capability  has  been  developed, 
upgraded  and  replaced  as  part  of  a center's  participation  in 
the  current  manned  space  program.  Simulators,  trainers, 
computer  mainframes,  warehousing,  special  carriers  and  various 
test  and  evaluation  capabilities  have  been  put  in  place  with 
program  funding  and  have  taken  on  an  institutional  flavor. 

These  systems  have  become  integral,  in  some  cases,  to  the 
determination  of  center  roles  and  responsibilities  and 
therefore  are  considered  institutional  assets  in  many  minds.  In 
the  case  of  the  Space  Station  Program,  many  such  existing 
systems  will  be  required  in  addition  to  those  that  will  be 
added  as  part  of  the  development  program.  The  ability  to 
conduct  Space  Station  operations  over  the  thirty-year  life  of 
the  program  will  depend  on  the  long  term  maintenance  and 
replacement  of  these  systems.  The  Space  Station  represents  a 
far  more  comprehensive  commitment  to  institutional  support  than 
has  heretofore  been  required  by  an  Agency  program. 

The  panel  recommends  that  the  Program  Office  be  given  a 
maintenance  management  role  that  includes  the  oversight  of  the 
support  given  to  any  system  without  which  Space  Station 
operations  cannot  continue  or  the  loss  of  which  would  seriously 
degrade  station  operational  capability.  The  oversight  would 
include  the  review  of  maintenance  and  replacement  planning  for 
these  systems  and  a review  of  the  program  and  institutional 
funding  that  is  proposed  and  allocated  to  support  these 
systems.  It  would  be  inappropriate  in  this  context  for  the 
Space  Station  Program  to  micromanage  a center's  institutional 
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planning.  However,  the  oversight  of  all  the  assets  necessary  to 
conduct  Space  Station  operations  over  the  life  of  the  program 
is  a prudent  exercise  of  management  responsibility. 

GROUND  SUPPORT  EQUIPMENT 

With  the  repair  and  maintenance  capability  of  the  LOC 
established,  the  repair  and  maintenance  of  ground  support 
equipment  can  be  accommodated  in  the  same  facilities.  The 
requirement  to  acquire  technical  documentation,  to  provide  for 
complete  Logistics  Support  Analysis  (LSA)  and  to  anticipate 
long  term  support  issues  is  just  as  important  for  ground 
support  equipment  as  it  is  for  on-orbit  hardware.  The 
successful  long  term  support  to  the  on-orbit  hardware  and 
operations  activity  will  depend  on  the  prudent  and  diligent 
support  of  the  ground  equipment  infrastructure  and  the  assets 
necessary  to  maintain  and  repair  it. 

3. 2. 3. 2 MATERIAL  MANAGEMENT 

DESCRIPTION 

Material  management  is  the  process  by  which  serviceable  material 
is  provided  through  provisioning,  replenishing,  distributing, 
storing,  and  repairing  in  order  to  support  space  station  and 
user  operations.  The  objective  is  to  provide  the  best  opera- 
tional availability  from  specific  resources  or  a specific 
operational  availability  from  an  optimal  mix  of  resources. 

MATERIAL. 

Material  consists  of  reparable  and  nonreparable  spare  parts, 
end  items,  support  equipment,  modification  kits,  and  consumable 
space  station  supplies. 
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THE  PIPELINE. 

When  an  end  item  of  equipment,  subassembly,  or  recoverable 
spare  fails,  it  is  removed  and  replaced  with  a serviceable 
item,  or  it  is  removed,  repaired,  and  replaced  (see  the  Concept 
of  On-orbit  maintenance  in  section  3. 2. 3.1).  The  failed 
component  is  transported  to  a maintenance  activity  either 
on-orbit  (extremely  limited)  or  on-ground  where  it  is  repaired 
or  condemned.  If  repaired,  the  component  is  transported  to  a 
storage  facility  or  directly  to  the  user.  If  condemned,  a new 
item  is  procured  to  replace  it.  Ideally,  this  supply  pipeline 
functions  smoothly  so  that  no  breaks  occur.  The  Space  Station 
represents  a unique  challenge  for  the  supply  pipeline  concept. 
The  constrained  transportation  to  orbit  associated  with  Space 
Station  operations  will  require  a careful  integration  of  repair 
turn  around  times,  procurement  activity  and  resupply/return 
planning.  See  Figure  3-6  for  the  Pipeline  Process. 

CUSTOMERS. 


Customers  of  the  material  supply  system  are  on-orbit  space 
station  operators  or  users  who  need  the  spare  part  or  end  item 
to  replace  a failed  item,  to  change  out  an  item  before  it 
fails,  or  to  perform  minor  repairs  on-board  the  Space  Station. 
Serviceable  material  is  also  provided  to  on-ground  users  for 
storage  in  a warehouse  facility  for  future  use,  and  to  the 
maintenance  activity  for  the  repair  of  ground  support 
equipment,  orbital  support  equipment  and  returned  on-orbit 
hardware. 

STORAGE  FACILITIES. 

Facilities  are  required  to  receive,  store,  and  issue  material 
from  warehouses  located  at  KSC,  other  Centers,  contractor 
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FIGURE  3-6  THE  PIPELINE  PROCESS 


facilities,  user  facilities, and  on-orbit.  Storage  areas  are 
also  needed  in  on-ground  maintenance  facilities.  On-orbit 
storage  facilities  are  needed  for  spare  parts  held  to  replace 
critical  systems  ORUS  for  preventive  or  corrective  maintenance 
and  for  consumable  material  needed  to  perform  maintenance  and 
minor  repairs.  Additional  storage  facilities  are  needed  for 
temporary  holding  at  material  receipt  points  such  as  launch 
site  payload  integration  areas. 

SPARES  REQUIREMENTS  DETERMINATION 

The  range  and  quantities  of  spare  ORUs  and  LRUs  will  be 
projected  to  provide  the  best  system  availability  for  a 
specific  funding  level  or  to  minimize  funds  required  for  a 
desired  system  operational  availability.  Spares  requirements 
will  be  projected  item  by  item,  by  groups  of  items  or  by  class 
codes  for  bulk  items  to  determine  what  and  when  to  buy  and 
repair  for  purposes  of  budgeting,  and  scheduling,  initiating, 
and  executing  buy /repair  processes.  Actual  supply  system 
performance  and  system  availability  data  will  be  tracked  and 
monitored  for  trend  analyses  and  system  calibration. 

INVENTORY  MANAGEMENT  SYSTEMS. 

The  existing  Kennedy  Inventory  Management  system  (KIMS) 
performs  some,  but  not  all,  of  the  necessary  inventory 
management  functions.  This  system  should  be  either  expanded  to 
encompass  on-orbit  inventory,  distribution,  maintenance,  and 
procurement  functions,  or  designed  to  interface  with  other 
systems  performing  these  functions.  Existing  systems  will  be 
utilized,  where  practical.  The  Problem  Reports  and  Corrective 
Action  system  (PRACA),  for  example,  could  be  used  to  track 
performance  data. 
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DATA  FILES 


Historical  item  data  will  be  retained  for  trend  analyses,  for 
adjusting  item  information,  and  to  provide  an  audit  trail. 
Examples  of  the  data  include  unit  cost,  repair  cost, 
failure/deroand  rates,  repair  cycle  tiroes,  lead  times, 
transportation  times,  condemnation  rates,  next  higher 
assemblies,  item  criticality,  and  Source,  Maintainability  and 
Recoverability  codes. 

ASSET  VISIBILITY. 

The  location  of  all  assets  for  each  item  managed  by  NASA  will 
be  tracked  worldwide  and  spacewide.  The  location  of  material 
will  be  entered  into  and  maintained  current  in  an  automated 
data  system  both  on  the  ground  and  on-orbit.  The  estimated 
number  of  line  items  is  300,000.  See  the  white  paper,  "Space 
Station  Line  Items  Estimate”,  for  details.  Serial  number 
tracking  will  be  performed  for  all  items  used  on-orbit  and  for 
all  other  critical  items. 

SYSTEMS  IMPLEMENTATION. 

Systems  to  perform  the  functions  described  above  must  be 
designed  and  funded  so  that  they  are  in  place  and  operational 
before  the  end  of  Phase  C/D.  TMIS  should  provide  for  the 
additional  systems  and  interfaces.  In  addition,  the  management 
system,  inventory  management  functions,  initial  spares,  ground 
support  equipment,  storage,  maintenance,  and  distribution 
activities  must  be  in  place  and  operational  by  the  end  of  Phase 
C/D. 
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MANAGEMENT  STRUCTURE 


a)  Day-to-day  logistics  data  systems  operation  should  be 
centrally  managed  at  the  LOC.  The  Program  Office  role  is  to 
ensure  systems  compatibility  and  consistency  of  data  formats 
and  files,  among  all  Centers  and  compliance  with  Logistics 
Information  System  standards  regardless  of  the  location  where 
the  systems  are  to  be  operated. 

b)  Program  Office  budget  formulation  will  be  supported  by  all 
participating  centers  with  A responsible  for  consolidation  and 
verification  of  budget  inputs  from  the  centers  for  spare  parts, 
maintenance  requirements,  and  ground  support  equipment.  The 
budget  will  be  reviewed,  validated  and  submitted  to  the 
Administrator  through  Level  A. 

c)  The  LOC  will  provide  implementation  of  material  management 
processes  and  spares  management  for  common  items.  These  common 
items  include  items  for  the  common  GSE.  Item  Managers  will  be 
identified  for  the  common  GSE  and  will  support  the  equipment  at 
all  locations  within  the  program.  Item  managers  at 
participating  centers  initiate  procurement  actions,  track 
critical  items,  negotiate  repair  quantities,  and  schedule 
repairs  with  maintenance  activities,  both  in-house  and  on 
contract . 

DEVELOPMENT  PROGRAM  RECOMMENDATIONS 

a)  In  reviewing  the  Space  Station  Program  Definition  and 
Requirements  Document,  Section  6:  Function  and  Resource 
Allocation  (JSC  30000  Sec. 6 Rev. A)  we  found  a lack  of  volume 
and  mass  allocation  for  on-orbit  storage.  While  section  2.3  of 
the  document  calls  for  storage  allocations,  none  are  called  out 
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in  the  resource  allocation  tables.  In  our  opinion,  on-orbit 
storage  volume  and  mass  requirements  are  not  adequately 
perceived,  are  not  being  managed  and  may  turn  out  to  be  as 
critical  a problem  as  resupply /return  capacity.  The 
determination  of  on-orbit  storage  requirements  should  be 
delegated  to  the  Integrated  Logistics  Working  Group  under  the 
Program  Office  management  so  as  to  be  integrated  with  their 
resupply/ return  requirements  definition  task. 

b)  In  meetings  with  Phase  B contractors  and  Work  Package 
logistics  managers  we  derived  an  estimate  for  the  number  of 
line  items  that  would  be  found  in  the  Space  Station  inventory. 
Our  estimate,  documented  in  an  enclosed  white  paper,  is 
313,000  line  items.  The  draft  KSC  Facilities  and  Equipment 
Requirements  Document  available  to  the  Logistics  subpanel 
based  the  storage  requirements  on  an  estimate  of  only  60,000 
line  items.  In  our  opinion,  the  facility  requirements  for 
storage,  handling  and  repair  are  under-perceived  and  should  be 
reviewed  prior  to  further  commitment  to  facility  planning, 
storage,  handling,  and  repair. 

3. 2. 3. 3 TRANSPORTATION 

INTRODUCTION 

The  ground  transportation  requirements  for  the  operational 
Space  Station  Program  were  not  judged  to  be  demanding.  The 
development  program  will  require  some  unique  transportation 
capability  during  the  assembly  and  verification  phase,  but  the 
operational  phase  requirements  should  be  comparable  to  the 
current  demands  placed  on  the  Space  Shuttle  program.  It  is 
recognized,  however,  that  the  reconfiguration  of  the  Space 
Station  Processing  Facility  (SSPF)  at  KSC  to  support  experiment 
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processing  may  drive  out  unique  transportation  requirements  for 
evolutionary  activities. 

TRANSPORTATION  DESCRIPTION 

The  Space  Station  Transportation  System  is  comprised  of 
earthside  and  space  segments.  This  system  uses  a range  of 
vehicles  chosen  to  offer  economical,  efficient,  and  priority 
movement  of  human,  material,  consumable,  experimental,  and 
manufacturing  products  within  the  transportation  network. 

These  resources  support  D.S.  Government  and  commercial 
operators /users  and  international  partners.  The  LOCs 
Transportation  Manager  plans,  communicates,  coordinates, 
implements,  and  monitors  terrestrial  shipments  of  resources 
from  integration  centers,  technology  centers,  customers,  and 
vendors;  the  Transportation  Manager's  line  management  is  headed 
up  by  the  Traffic  Controller  who  resides  in  the  LOC.  The 
Traffic  Controller  is  responsible  for  real-time  shipment 
requests,  arrivals  on  dock,  and  shipment  schedule  changes. 
Duties  include  achieving  shipment  arrival  deadlines  set  by 
other  Space  Station  line  organizations  to  assure  timely  and 
effective  on-orbit  Space  Station  support.  Variations  in 
established  shipping  schedules  and  their  perturbations  are 
analyzed  and  alternate  solutions  to  needs  are  developed  through 
considerations  of  priority  shipping  modes,  alternate  sourcing, 
and  other  alternatives  of  fulfilling  resource  requirements.  An 
important  element  of  the  terrestrial  transportation  network  is 
the  KSC  transportation  node,  a depot  for  truck,  rail,  and  air 
shipments,  both  D.S.  and  international.  Customs  Service 
processing  at  this  depot  facilitates  international  material 
shipments,  permitting  direct  arrivals  from  international  sites 
to  be  expeditiously  processed  for  integration  into  space 
transportation  segment  cargos.  The  KSC  Receiving  and  Shipping 


Section  processes  arriving  material  to  the  Space  Station 
Logistics  Support  Facility  for  storage,  load  integration, 
off-line  payload  integration  and  checkout,  or  movement  to  other 
ground  support  or  operations  facilities  for  other  purposes. 
Status  of  inbound  and  outbound  shipments  in  the  Receiving  and 
Shipping  Section  is  maintained  in  the  LOC  via  computer/ 
telephone. 

SCHEDULING 

Ground  segment  transportation  schedules  pivot  about  the  45-day 
resupply  cycle  and  the  recoveries  of  returning  material  nomi- 
nally 7 to  10  days  after  resupply  launches.  The  45-day 
resupply  flight  cycle  is  treated  as  an  inviolate  planning 
factor  to  assure  the  best  possible  support  of  on-orbit  missions 
and  operations.  More  than  10  years  of  Space  Station  operation 
have  allowed  increasing  flexibility  in  resupply  frequency. 
Continuing  reliability  improvements  of  installed  systems  yield 
increasing  resupply  and  return  cargo  capacity  for  experiment 
and  manufacturing  materials  and  products.  Thus,  while  Space 
Station  operations  support  requirements  are  decreasing,  user 
requirements  are  expanding  to  optimize  use  of  up  and  down  cargo 
capacity.  Crewmember  rotations  are  nominally  at  90-day 
intervals.  While  the  Shuttle  is  the  primary  space 
transportation  vehicle  for  Space  Station  support,  the  variety 
of  expendables,  partially  reusable  and  reusable  vehicles  play 
an  increasing  role.  Periodically,  fly-in  maintenance  crews 
bring  all  needed  resources  to  accomplish  periodic  maintenance 
and  modernization  of  Space  Station  systems.  This  innovation 
was  made  possible  by  the  enhancement  trends  in  systems 
hardware,  firmware,  and  software.  Exceptional  requirements  for 
systems  components  occur  infrequently,  necessitating  priority 
shipments  via  the  most  efficient  or  available  vehicle  for  the 
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task;  e.g.,  an  expendable  or  the  aerospace  plane.  On  rare 
occasion,  other  countries'  vehicles  are  used  to  fill 
out -of -schedule  resupply /return  needs,  primarily  in  support  of 
the  international  partners'  Space  Station  activities. 

LOAD  PLANNING 

Resupply  and  return  load-plans  are  initially  computer-generated 
based  on  firm  and  projected  requirements  for  station  and  user 
material.  These  requirements  derive  from  periodic  component 
change-outs  and  predicted  failures  of  other  components  based  on 
performance  trend  analysis.  Also  included  are  requirements  for 
user  experiments  and  manufacturing  materials  and  on-board 
housekeeping  materials.  As  actual  requirements  continually 
flow  into  the  data  base  from  the  condition  monitoring  and 
transmission  systems  incorporated  within  installed  Space 
Station  and  user  systems,  resupply  load-plans  for  systems 
support  are  firmed  up.  Cargo  preparation  and  loading  flow 
times,  based  on  trials  and  experience,  are  factored  into  the 
automated  manifesting  routine,  with  management  margins  to  add 
confidence  in  the  routine's  schedules.  Material  stowage 
patterns  are  included  in  the  automated  manifesting  program  to 
minimize  need  for  human  interference  with  this  sophisticated 
expert  system;  factored  in  are  packaged  item  physical 
characteristics  of  weight,  volume,  stress  sensitivities,  and 
environmental  control  requirements.  Items  to  be  used 
immediately  are  placed  in  the  cargo  container  for  quick  access 
upon  arrival  at  the  Space  Station,  and  the  efficient,  rapid 
shifting  of  cargo  items  for  this  accommodation  is  done  in 
accordance  with  specific,  detailed  instructions  provided  to  the 
handler  through  the  manifesting  program.  The  duration  of 
prelaunch  cargo  manipulation  periods  is  vehicle  dependent, 
dictated  by  vehicle  preflight  servicing  and  checkout  re- 
quirements. Major  cargo  changes  are  possible  up  to  within 
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minutes  of  launch  or  takeoff  of  the  transatmospheric  vehicle 
the  "Orient  Express",  within  less  than  a day  for  the  Shuttle 
and  other  vehicles. 

ON-ORBIT  MOVEMENT 

Space-based  orbital  maneuvering  vehicles  (OMV)  are  proving  to 
be  extremely  useful  for  shifting  resource  containers  from 
launch  vehicles  to  the  Space  Station  and  back  to  return 
vehicles.  This  capability  is  used  primarily  for  cargo  transfer 
from  expendable  and  partially  reusable  vehicles  and  the 
aerospace  plane,  and  for  shuttling  between  the  station  and  the 
Orbiter.  While  OMV's  are  mainly  used  for  servicing  free-flyers 
and  co-orbiting  platforms  and  for  manipulating  new  station 
modules  and  other  exterior  modifications,  there  is  a sufficient 
quantity  of  these  versatile  craft  to  perform  the  shuttling 
activities.  Orbital  transfer  vehicles  (OTV)  derived  from  the 
OMV  are  nearing  the  test  and  evaluation  phase.  The  OTV  will  be 
crucial  to  recovery  of  valuable  but  unserviceable  communications 
and  weather  satellites  in  geosynchronous  orbits.  Once  brought 
back  to  LEO  station  environs,  repairs  can  be  affected  on  these 
satellites  and  they  can  be  replaced  in  geosynchronous  locations 
by  OTVs.  Additional  OTV  applications  for  lunar— base  and 
geo-shack  buildup  and  for  resupply  are  planned  to  begin  in  the 
2017-2020  era  of  space  resource  exploitation  and  exploration. 

3. 2. 3. 4 TRAINING 

The  basic  concept  for  Space  Station  training  as  discussed  in 
section  four  of  the  Panel  1 report  has  been  considered  as  an 
approach  to  build  upon  for  application  to  ground  operations  and 
logistics  activities.  The  expansion  to  include  ground 
operations  skills  development  as  discussed  in  the  training 
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plans  for  the  Shuttle  Processing  Contractor  and  the  Payloads 
Ground  Operations  Contractor  will  complete  the  scope  of 
training  to  be  considered.  The  generic  development  of  managers 
and  the  maintenance  of  engineering  skills  should  also  be 
included  in  Space  Station  training  discussions,  particularly  as 
applied  to  the  contractor  work  force. 

A comprehensive  Space  Station  training  system  requirements 
analysis  should  be  undertaken  before  assuming  the  manpower  and 
resources  intensive  role  model  provided  by  the  STS.  It  is 
expected  that  crewpersons  will  not  fly  many  missions  due  to 
health  concerns  and  career  growth  pressures.  The  training 
program  will  therefore  have' to  respond  to  a large  turnover  of 
personnel  with  repeat  crewpersons  essentially  starting  all 
over.  The  application  of  the  current  STS  role  model  to  the 
Space  Station  crew  rotation,  as  discussed  in  the  Panel  1 
report,  will  require  a prohibitive  investment  in  training 
development  and  maintenance. 

The  Space  Station  Training  Coordination  Board  (STCB)  as 
proposed  by  Panel  1 should  be  strengthened  to  become  a firm 
program  management  element.  A rotating  chairmanship  will  not 
provide  the  necessary  management  direction  to  ensure  the 
consistent  quality  in  training  required  to  sustain  the  program. 
Rather,  the  Program  Office  chairmanship  is  recommended  for 
consistency  and  continuity.  However,  the  systems  approach  to 
training  development  and  delivery,  as  discussed  by  United 
Airlines  during  their  January  15,1987  briefing  to  the  Task 
Force,  (Figure  3-7)  does  have  the  desired  program  structure. 
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TOTAL  TRAINING  SYSTEM 
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FIGURE  3-7  TOTAL  TRAINING  SYSTEM 


3. 2. 3. 5 PACKING  AND  HANDLING 


DESCRIPTION 

Packing  and  handling  are  those  processes  by  which  material  is 
prepared  for  transportation.  In  the  case  of  transportation  to 
and  from  orbit,  the  packing  must  protect  the  material  from 
damage  during  the  launch  and  reentry  phases.  The  vibration, 
thermal  and  vacuum  environments  that  material  are  subjected  to 
can  be  severe  for  both  the  Space  Shuttle  and  Expendable  Launch 
Vehicles.  In  the  case  of  ground  transportation,  the  hazards  to 
material  can  be  severe  even  in  local  on-site  moves.  Packing  and 
handling  specifications  are  part  of  the  technical  documentation 
developed  during  the  Phase  C/D  activities  or  are  provided  by 
the  specific  user  design  agent.  In  some  cases  material  will 
have  to  be  repacked  between  ground  transportation  and 
transportation  to  orbit. 

MANAGEMENT 

The  packing  and  handling  function  will  be  integrated  by  the 
logistics  operations  manager  with  the  efforts  of  inventory 
management,  maintenance  management  and  resupply /return 
management.  The  timely  preparation  of  material  for  shipment  to 
and  from  orbit,  to  and  from  the  repair  process  and  locally  at 
the  operations  center  is  essential  to  maintaining  processing 
schedules.  A logistics  operations  manager  is  responsible. 
Automated  tracking  of  material  through  the  packing  and  handling 
function  would  be  performed  by  an  appropriate  module  of  the 
Logistics  Information  System. 
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LOGISTICS  CARRIER  PREPACKING 


A significant  portion  of  the  material  transported  to  and  from 
orbit  will  not  require  the  verification  and  checkout  process 
discussed  in  Section  5.3.  These  items  which  represent  30  to  50 
percent  of  the  cargo  transported  are  the  non-experiment 
hardware,  user,  system  and  crew  consumables  and  the  materials 
and  tools  associated  with  maintenance  and  modification 
activities.  Since  the  processing  of  these  materials  will  not 
require  an  extensive  interface  with  the  ground  data  management 
system  or  any  on-board  interface  verification,  they  can  be 
prepacked  in  the  logistics  facility  and  installed  in/on  the 
logistics  carriers  as  part  of  the  processing  activity.  By 
prepacking  at  the  rack  or  drawer  level,  on-line  processing  time 
for  these  materials  can  be  minimized.  Hazardous  fuels  and 
fluids  carriers  will  have  to  be  processed  off-line  for  safety 
reasons  and  will  be  loaded  in/on  the  STS  or  ELV  independently. 

For  those  items  which  will  be  returned  from  orbit  for  repair  or 
reuse,  the  packing  design  must  facilitate  on-orbit  storage  and 
require  a minimum  of  crew  handling  time  as  the  material  arrives 
and  leaves  the  Space  Station.  The  integration  of  this 
requirement  into  the  overall  on-orbit  storage  approach  will  be 
a key  design  task. 

3. 2. 3. 6 FACILITIES 

INTRODUCTION 

The  facilities  required  to  support  the  logistics  functions  at 
the  operations  center  fall  in  three  main  categories,  ware- 
housing including  space  for  offices  and  training  activities, 
repair  and  maintenance  facilities  and  a logistics  carrier 
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prepacking  and  unpacking  facility.  For  the  purposes  of  this 
discussion,  it  is  assumed  that  the  facilities  to  support 
logistics  functions  at  distributed  integration  and  operations 
sites  are  provided  by  the  site  managers  or  institutions 
involved. 

WAREHOUSING 

The  Space  Station  logistics  warehouse  will  be  a fully  automated 
"lights  out”  facility.  Through  the  use  of  automated  store  and 
issue  equipment  and  the  use  of  smart  tags  and  similar 
technologies,  the  need  for  warehouse  handling  personnel  will  be 
minimized.  More  conventional  staffing  will  be  required  for  the 
receipt,  inspection,  packing,  shipping  and  material  service 
center  functions. 

Several  Space  Station  Program  unique  storage  requirements  were 
identified.  The  planned  thirty-year  program  life  and  the 
anticipated  flow  of  specialized  experiment  hardware  will 
require  a capability  to  store  special  shipping  containers  and 
pallets.  Experiment  rack  shipping  containers,  special 
containers  to  support  the  shipping  of  Space  Station  systems, 
consumables,  and  fluids  are  proposed  as  a program  supplied 
item.  Users  are  expected  to  have  similar  requirements  to 
support  servicing  in  addition  to  containers  for  ground  and  to 
and  from  orbit  transportation  . There  may  also  be  a requirement 
to  store  experiment  racks  between  the  time  they  are  shipped 
from  the  integration  center  and  the  scheduled  need  date  at  the 
operations  center. 

Two  approaches  were  employed  to  size  the  warehousing 
requirement.  The  analysis  is  presented  in  white  paper,  "Space 
Station  Line  Items  Estimate”  by  Ray  Norman.  Both  cases  produced 
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an  estimate  of  300,000  line  items  of  inventory.  This  finding 
has  been  forwarded  to  Space  Station  Program  management  for 
their  consideration  since  it  represents  a factor  of  five 
increase  in  the  estimate  that  is  currently  anticipated  by  the 
program. 

REPAIR  AND  MAINTENANCE 

As  previously  discussed  under  ground  maintenance,  the  majority 
of  repair  of  Space  Station  system  OROs  and  operations  center 
ground  systems  LRUs  will  be  accomplished  in  an  on-or-near  site 
depot  maintenance  facility.  This  facility  will  have  the 
capability,  using  automated  test  equipment,  to  analyze  ORU 
failure  modes  and  isolate  the  failed  SRUs  and/or  piece  parts. 

In  addition,  this  same  equipment  will  be  used  in  the  return  to 
orbit  recertification  testing  activity. 

The  scope  of  required  repair  capabilities  is  very  broad.  The 
current  concept  of  self-sufficiency  would  demand  that  the 
operations  contractor  have  a variety  of  repair  capabilities.  It 
is  suggested  that  there  may  be  a synergistic  set  of  repair 
capabilities  that  would  support  the  Space  Station  and  the  Space 
Shuttle  programs  as  well  as  the  operations  center  institutional 
support  requirements.  The  following  is  a list  of  capabilities 
anticipated  as  Space  Station  Program  requirements: 

ELECTRONIC  REPAIR  AND  REMANUFACTORE 
ELECTRICAL  FABRICATION 
GAS  AND  FLUID  SAMPLING  AND  ANALYSIS 
PROOF  LOADING 

CLEAN  ROOMS /LAMINAR  FLOW  BENCHES 
SEWING  AND  FABRIC  REPAIR 
PNEUMATIC  REPAIR 
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PAINTING  AND  COATINGS  APPLICATION 

CHEMICAL  PROCESSING 

FOOD  PROCESSING 

ENVIRONMENTAL  TESTING 

RECERTIFICATION  TESTING 

WASTE  PROCESSING 

HYDROSTATIC  TESTING 


LOGISTICS  CARRIER  PREPACKING 

As  discussed  in  Section  3. 2. 3. 6,  Packing  and  Handling,  the 
prepacking  of  non-experiment  hardware  and  consumables  is 
proposed  as  a logistics  facility  function  to  facilitate  ground 
processing.  The  hazardous  fuels  and  fluids  processing  is 
assumed  to  be  accommodated  through  the  use  of  existing 
operations  center  capabilities.  The  prepacking  of  logistics 
carrier  drawers  and  racks  will  require  additional  facility 
capability  over  current  program  plans.  A clean  room  environment 
is  viewed  as  a requirement  for  prepacking  racks  and  drawers 
destined  for  the  pressurized  logistics  carrier.  The  cleanliness 
quality  of  this  clean  room  is  assumed  comparable  with  the 
experiment  processing  facilities. 

FACILITIES  COST  AND  PHASING 

The  Space  Shuttle  Logistics  Facility  has  been  used  as  a model 
for  cost  estimating  purposes.  For  estimating  purposes  we  have 
also  assumed  that  the  warehousing,  repair,  and  prepacking 
facilities  could  be  co-located.  The  estimated  amounts  are: 
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Description 

Construction  of  Facilities 

Warehouse  Equipment 

Test  Equipment  & Software 

Operational  Manyears  (MYR) 

Senior  manager  20 
Middle  manager  40 
Technician  400 

Repair  200 

Material  Mgt  150 
Procurement  50 

The  warehousing  capability  should  be  in  place  to  support 
initial  assembly  and  checkout  activities.  This  would  require 
that  the  facility  be  available  one  year  prior  to  first  launch. 
Two  years  are  estimated  for  construction  and  equipment 
installation  and  check  out.  A total  of  five  years  is  the  norm 
for  new  COF  projects.  The  phasing  of  the  repair  capability  is 
proposed  to  be  consistent  with  the  assumption  of  the  repair  and 
maintenance  management  role  by  the  LOC  at  ORU  launch  plus  one 
year.  Thus  the  test  and  repair  equipment  acquisition, 
installation,  checkout  and  certification  will  be  driven  by  the 
launch  package  schedule.  It  is  estimated  that  eighteen  months 
to  two  years  will  be  required  to  install,  check  out  and  certify 
the  repair  and  test  equipment.  Acquisition  lead  times  were  not 
estimated  and  are  additive.  Logistics  carrier  prepacking  and 
unpacking  capability  must  be  in  place  with  the  onset  of  resupply 
and  return  missions. 


Million  Man 

Dollars  Years 

$ 30. 

15. 

30. 

460 
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3. 2. 3. 7 TECHNICAL  DOCUMENTATION 


Technical  data  or  documentation  is  the  paper,  audio-visual, 
optical  or  magnetically  stored  information  which  is  used  in 
system  assembly,  checkout,  operating  and  maintenance 
instructions,  inspection  and  calibration  procedures,  overhaul 
procedures,  modification  instructions,  time  compliance  and 
technical  instruction,  modification  kits  instructions,  drawings 
and  specifications  and  reprocurement  information  that  are 
necessary  for  the  performance  of  Space  Station  system 
operations . 

The  data  will  be  developed  by  the  Work  Packages  and  their 
contractors  during  Phase  C/D  as  a result  of  needs  definition 
through  the  Logistics  Support  Analysis  process.  That  process 
will  also  identify  appropriate  formats  and  media  for  the 
various  data  applications  described  earlier. 

The  development  of  the  documentation  occurs  in  conjunction  with 
hardware  and  software/firmware  design  and  development,  with  the 
verification  complete  before  or  no  later  than  the  first  need 
date.  Since  trained  technical  documentation  users  are  required 
at  the  need  date,  the  related  technical  documentation  must  be 
ready  in  advance  of  the  operational  need  date  by  the  amount  of 
time  required  to  develop  training  materials,  coordinate  and 
checkout  training  facilities  and  equipment,  train  instructors 
and  conduct  necessary  qualification  and  certification 
training. 

We  would  require  that  the  training  and  certification  process  be 
tested  using  the  verified  technical  documentation  to  ensure 
adequacy  and  accuracy.  This  training  verification  is  referred 
to  as  Personal  Reliability  Programs,  Standboards,  etc. 
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The  technical  documentation  data  base  will  be  a partitioned 
resident  of  the  TMIS  integrated  system.  Opdating  technical 
documentation  will  be  a joint  function  of  all  users  and 
monitors,  with  Sustaining  Engineering  assigned  overall 
responsibility.  Logistics  Engineering  and  Configuration 
Management  have  coordination  responsibility  on  proposed 
revisions.  Accomplishment  of  this  coordination  and  an  approval 
process  will  assure  requisite  interfaces  with  the  operations, 
training,  supply  and  procurement  disciplines  to  permit  their 
actions  necessary  to  stay  current  for  optimum  Space  Station 
success. 

Through  development  of  systems  design,  documentation  for 
maintenance  processes  is  derived  with  assembly  and  integration 
process  documentation.  After  development  contractor  derivation 
and  commitment  to  the  assigned  media,  the  documentation  is 
validated  by  the  PGOC  and/or  integration  contractor  for  process 
completeness,  accuracy  and  effectiveness.  A Government 
verification  process  will  be  demonstrated  by  representative 
users  prior  to  acceptance  by  the  LOC. 

Technical  data  and  documentation  verification  and  acceptance 
will  be  complete  before  the  first  element  launch,  as  a part  of 
the  Phase  C/D  process.  After  acceptance  by  the  LOC,  the 
complete  data  package(s)  will  be  transferred  to  the  Space 
Station  documentation  repository/TMIS  and  be  available  for  the 
Logistics  Information  System  for  use. 

One  of  the  recent  ('87)  techniques  described  in  the  AIAA 
proceedings  and  manufacturers'  wish  lists  are  the  portable  or 
battery  powered,  no  hands,  heads  up,  helmet  projection 
procedure /drawing  instruction  for  extra  vehicular  activity. 

One  can  envision  an  astronaut  who,  by  voice  command,  can  cause 
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a video  picture  to  be  projected  in  his  helmet.  Also,  by  voice 
command,  he  makes  a drawing  isometric  rotate,  enlarge  or  reduce 
in  an  in-helmet  overlay  of  the  actual  picture  of  the  device 
that  he  is  working  on  at  the  time. 

One  can  extend  this  thinking  to  the  2010  astronaut  who  can  have 
a direct  projection  of  this  optical  image  on  the  retina.  Even 
the  very  simplest  applications  will  be  voice  activated  and  have 
touch  screens  employed  at  repair  work  sites  at  the  LOC  and 
on-orbit  in  the  SS. 


3. 2. 3. 8 Oser  Support 


Space  Station  logistics  support  requirements  for  the  user  in 
the  2010  timeframe  are  based  on  the  definition  of  users.  Users 
can  be  participants,  customers,  international  partners,  principal 
investigators  (Pis),  and  other  U.S.  government  agency  partners. 

This  section  addresses  the  logistics  support  requirements  of 
the  international  partners,  and  will  touch  on  the  otHer  users 
mentioned  above.  The  assumptions  used  in  this  section  are: 


1.  Users  are  participants 

2.  Customers  are  participants 

3*  Partners  are  the  internationals  and  other  U.S.  government 
agencies . 


INTERNATIONAL  PARTNER  SUPPORT 


All  three  international  partners  have  indicated  that  it  is  too 
early  to  define  their  total  logistics  support  requirements  for 
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the  year  2010.  However,  the  Japanese  did  present  their 
resupply /return  requirements  and  capabilities  for  the  year  2010 
as  follows: 

Resupply  100  tons/yr  (15-30  tons/yr  for  JEM) 

Retrieval  20  tons/yr  ( 5-10  tons/yr  for  JEM) 

Therefore:  10/20  tons/yr  stays  up  on  JEM 

Estimates  up  to  25  tons/yr  of  garbage 
Estimate  resupply  capability  of  H2  is  40tons/yr  (4 
Launches-include  logistics  module(s)  of  10  tons) 
Advanced  H2  proposed  has  capacity  for  resupply  of 
60-120  tons/yr  proposed 

In  general,  the  International  partners  have  indicated  a desire 
for  facilities  at  KSC.  These  facilities  would  include  storage, 
prelaunch/post-launch  recovery  processing,  warehousing,  and 
office  space-.  If  the  Arienne  5 (ESA)  and  H-2  (Japan)  vehicles 
are  available  in  the  2010  time  frame,  then  ESA  and  Japan  will 
probably  use  the  co-located  launch  and  operational  centers  in 
French  Guiana  and  TKSC,  Japan.  Most  logistics  support  such  as 
storage,  prelaunch,  post  recovery,  warehousing,  and  office 
space  would  be  located  at  the  appropriate  international  launch 
site. 

Operations  and  logistics  will  be  the  major  cost  elements  in  the 
year  2010.  ESA  and,  even  more  so,  Japan  have  indicated  their 
desire  for  complete  autonomy  for  their  modules  and  platforms  in 
the  Space  Station  Program.  They  assume  this  would  keep  their 
costs  down  and  minimize  the  exchange  of  funds  among  countries. 
Therefore,  both  Japan  and  ESA  would  like  to  have  their 
logistics  and  operations  functions  based  in  their  respective 
countries.  All  partners  and  users  availing  themselves  of  the 
Space  Shuttle,  however,  will  have  to  use  the  facilities  at  KSC 
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for  processing  their  elements.  Partners  may  want  or  need  to 
use  facilities  at  other  locations  as  well,  for  example,  the 
power  test  facility  at  NASA-Lewis  so  that  partners  could  verify 
their  power  systems  prelaunch/post-recovery  performance. 

Canada  will  depend  heavily  on  NASA  expertise  for  their 
operational  logistics  support,  partly  because  of  cost  and 
partly  because  of  the  relatively  small  size  of  the  Canadian 
Space  Station  organization.  The  bulk  of  NASA  logistics  support 
for  Canada  would  be  at  KSC  with  some  logistics  support  possible 
for  the  interaction  between  JSC's  movable  platform  and  truss 
and  Canada's  mobile  servicing  system  (MSS).  Acquisition 
logistics  support  for  the  Canadian  MSS  will  be  done  in  Canada 
to  provide  procurements  of  spare  parts,  tools  and  technical 
documentation . 

It  is  also  probable  that  NASA,  ESA,  Japan,  and  all  other 
experimenters  will  need  to  interact  with  Canada's  logistics 
organization,  especially  if  their  pay loads /experiments  are 
external  and  use  the  Canadian  arm  for  positioning  and 
servicing. 

If  either  ESA  or  Japan  can  offer  the  Canadians  a better  pricing 
structure  than  NASAs  for  launch  services,  the  Canadians  can 
offset  the  higher  costs  of  ground/air/sea  transportation  to  ESA 
or  Japanese  launch  sites.  The  Canadians  would  then  use 
ESA/ Japanese  launch  services,  and  be  tied  into  logistics 
support  from  ESA  or  Japan. 

For  the  international  partners,  logistics  support  will  be 
negotiated  and  included  in  international  top  level  agreements 
dealing  with  program  element  contributions  and  requirements  on 
both  parts.  Such  intergovernmental  agreements  often  use 
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annexes  to  top-level  program  documents  to  define  variance  in 
the  program  requirements  as  negotiated  between  the  parties 
affected*  Waivers  of  requirements  may  be  granted  to 
internationals  on  an  as  required  basis.  An  issue  for  early 
consideration  is  the  need  for  standardized  interfaces  with  the 
LOC  managed  Space  Station  support  systems.  Standardized 
interfaces  will  ensure  appropriate  user  support  systems 
development,  smooth  functioning  of  logistics  systems,  and 
maximized  support  efficiency. 

Forums  that  could  support  logistics  interface  definition  would 
be  working  groups  such  as  the  International  Operations  Working 
Group  ( IOWG ) , International  Cooperation  Working  Group  (ICWG), 
and  ILWG.  Some  agreements  can  be  formalized  through  authorized 
working  groups  speaking  for  both  NASA  and  the  participant.  If 
use  of  NASA  facilities  at  KSC  or  elsewhere  is  planned  or 
desired  by  any  of  these  users,  negotiations  with  NASA  Level  A, 
the  Program  Office  and  appropriate  NASA  centers  is  necessary 
early  in  the  program  to  minimize  schedule  and  cost 
perturbations  to  the  Program  and  the  users'  efforts.  Other 
logistics  element  planning,  development  and  emplacement  must 
occur  parallel  with  NASA  Space  Station  Program  logistics 
milestones.  Issues  could  be  settled  by  the  Program 
Coordination  Committee  (PCC). 

OTHER  USER  SUPPORT 

Participants  may  include  Universities,  principal  investigators 
(PI),  industry,  DOD,  other  government  agencies,  and 
internationals  other  than  ESA,  Canada  and  Japan.  Participants 
would  require  the  same  NASA  logistics  support  as  discussed 
above.  However,  as  an  alternative,  they  could  ship  their 
payloads/experiments  to  KSC  ready  to  launch.  Any  logistics 
support  required  will  be  negotiated  on  a case-by-case. 
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DOD  experiments  would  be  located  on  the  O.S.  portion  of  the 
Space  Station  and  DOD  will  provide  the  primary  operations  and 
logistics  support.  When  security  is  pertinent,  the  DOD  would 
be  expected  to  use  KSC/CCAFS  facilities. 

Also  desired  are  facilities  and  logistics  support  at  KSC  and 
other  landing  sites  for  Life  Sciences  programs  which  would 
permit  early/ late  access  to  the  logistics  carriers.  The 
capabilities  and  equipment  to  support  this  activity  would 
include  staging  areas,  controlled  environments,  test  equipment, 
means  of  transportation  to  and  from  the  launch  site,  payload 
installation/removal,  handling,  storage,  office  space  and,  in 
some  cases,  data  analysis.  Logistics  support  is  also  required 
for  "Quick  Sample  Return"  and  "Emergency  Crew  Return" . The 
support  required  for  these  scenarios  would  include  coordination 
with  other  O.S.  government  agencies  such  as  the  O.S.  Navy  for 
recovery,  special  handling  facilities  and  transportation. 

If  Oniversities,  Pi's  and  O.S.  Industry  locate  their 
experiments  in  the  Japanese  or  ESA  module,  they  must  interact 
with  Japan's  or  ESA's  Program  Office  for  their  logistics 
support  needs.  In  one  scenario,  these  experiments  would  be 
located  in  either  the  JEM  or  ESA  Module  and  launched  by  the 
O.S.  from  KSC.  Another  scenario  would  be  0.  S.  experiments 
located  in  the  JFM  or  ESA  modules  and  launched  by  H-2  or 
Arienne  5.  This  scenario  would  significantly  complicate  the 
O.S.  experimenter's  logistics  support  options,  with  little  or 
no  control  by  the  0.  S.  experimenters  at  the  International 
launch  sites.  Other  international  experimenters  might  contract 
with  ESA  or  Japan  for  their  logistics  support,  particularly  for 
ESA  or  JEM  hosted  payloads. 


3-72 


3. 2. 3. 9 RESOPPLY /RETORN 


Reaupply/ return  is  not  a classical  logistics  function.  It  is  a 
combination  of  such  functions  which  require  joint  management 
because  of  the  unique  transportation  bottleneck  that  the  Space 
Shuttle  presents  to  the  Space  Station  Program.  The  major 
resupply /return  tasks  are  described  in  Table  3-6. 

One  of  the  most  disturbing  findings  of  the  Logistics  Subpanel 
was  the  lack  of  resupply /return  requirements  management  on  the 
part  of  the  Space  Station  Program  and  the  current  inability  of 
the  program  to  support  the  requirements  known  at  this  time.  The 
current  requirements  exceed  the  Space  Shuttle/ Logistics  Carrier 
capability  by  approximately  35,000  pounds  upmass  and  150,000 
pounds  downmass  annually.  The  credibility  of  the  requirements 
estimates  is  admittedly  low.  Many  of  the  requirements  should  be 
more  appropriately  considered  as  "user  desirements" . A "desire- 
ment"  being  defined  as  a requirement  on  the  part  of  someone  who 
has  no  funding  or  approved  program.  The  other  major  exacerbation 
is  the  degrading  availability  of  the  Space  Shuttle  as  an 
on-orbit  delivery  vehicle.  In  recent  reports  both  the  Aerospace 
Safety  Advisory  Panel  and  the  Shuttle  Processing  Contract 
Review  Team  recommended  reductions  in  flight  rate  below  the 
sixteen  per  year  that  the  Space  Station  operations  planning 
assumes.  The  current  resupply /return  analysis  assumes  eight 
dedicated  shuttle  flights  a year.  Any  reduction  in  the  availa- 
bility of  the  Space  Shuttle  will  have  obvious  consequences. 
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TABLE  3-6 

o Strategic, tactical  and  execution  level  planning  of  mass 
and  volume  for  materials  necessary  to  support  a given 
increment 

o On-orbit  storage  planning  and  inventory  management  to 
support  a given  increment 

o Logistics  carrier  load  planning  and  inventory 
management 

o Launch  vehicle/ logistics  carrier  utilization 
management 

o Orchestration  of  the  preparation/acquisition/delivery 
of  the  necessary  materials,  technical  documentation  and 
training  to  support  a given  increment 


The  Logistics  Subpanel  recommends  that  the  Integrated  Logistics 
Working  Group  be  revitalized  and  their  assignment  to  manage 
resupply /return  requirements  be  vigorously  pursued.  Further, 
that  the  Space  Station  Program  reassess  the  realities  of  the 
degrading  availability  of  Space  Shuttle  and  aggressively 
examine  expendable  launch  vehicle  alternatives  for  accomplish- 
ing resupply /return.  In  addition  the  long  term  management  of 
resupply/ return  should  be  considered  for  delegation  to  the  LOC 
to  facilitate  the  synergistic  management  of  maintenance, 
resupply/return  and  the  logistics  infrastructure  that  support 
the  program. 


3.3  OTHER  OPTIONS 


INTRODUCTION 

The  Logistics  subpanel,  early  in  its'  deliberations,  examined 
alternative  approaches  for  support  required  in  major  logistics 
functional  areas.  This  was,  by  no  means,  an  exhaustive  review 
of  all  logistics  functions,  but  covered  those  areas  where 
selection  of  one  approach  over  other  potential  approaches  had 
the  greatest  impact  on  the  organization  and  planning  of  Space 
Station  support.  The  categories  reviewed  are  identified  in 
Table  3-7. 
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TABLE  3-7 


Li  - ILS  Planning/Management 

L2  - Maintenance  Scheduling 

L2A  - Orbital  Hardware  Supported  On-Orbit 
L2B  - Orbital  Hardware  Supported  On-Ground 
L2C  - Ground  Equipment  Supported  on-Ground 

L3  - Maintenance  Execution 
L3A  - On-Orbit 
L3B  - On-Ground 

L4  - User  Autonomy /International  Participation 
On-Orbit  and  On-Ground 

L5  - Transportation  to  Orbit 

L6  - Evolution 

L7  - Original  Equipment  Manufacturers  Support  Strategy 


Within  each  functional  category,  support  subfunctions  were 
identified  and  defined.  Each  panel  member  scored  each  sub- 
function on  a scale  of  1 to  5 (with  1 being  the  least  accept- 
able alternative  and  5 the  most  acceptable)  for  each  of  the 
following  elements: 

1.  FEASIBILITY  - "Doable,”  capable  of  being  carried  out  to 
completion. 

2.  FLEXIBILITY  - Capable  of  responding  to  new  situations,  i.e. 
space  station  growth  and  evolution  to  a new  configuration;  does 
not  (necessarily)  have  to  be  scrapped  or  junked  to  viably 
adapt . 

3.  USER  FRIENDLY  - Provides  easy  training  for  and  use  to  a 
journey  level  person  with  average  intellect  and  motor  sensory 
skil 1 /perception . 

4.  EFFECTIVENESS: 


a.  Transition  - How  easy  is  it  to  go  from  Phase  C/D  to 
Phase  E (Operational)? 

b.  Management  - Does  this  option  lend  itself  to  "effec- 
tive" management  skills,  tools? 

c.  Cost  - What  is  the  relative  life  cycle  cost  of  one 
option  compared  to  other  options  for  the  function  or 
subfunction? 

d.  Performance  - Is  it  capable  of  doing  the  function  in  a 
timely  and  sufficient  (all  that  is  required)  manner? 
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5.  SAFETY  - What  is  the  relative  risk  of  bodily  harm  or 
hardware/firmware/software  damage? 

6.  TERMINATION  - Can  this  option  be  terminated/  eliminat- 
ed/phased out  without  terminating  the  total  station/  having 
cataclysmic  effects? 

Functional  interdependences  were  considered  and  conflicts  were 
resolved.  The  panel  collectively  agreed  on  a single  value  for 
each  subfunction  and  element,  and  a total  score  was  tallied  for 
each  subfunction.  Table  3-8  displays  the  scores  for  each 
subfunction  and  scoring  element. 

All  subfunctions  were  reviewed  in  terms  of  the  ultimate  objec- 
tive of  optimum  Space  station  support.  The  key  criterion  for 
evaluating  support  in  all  of  these  areas  is  achieving  the 
highest  possible  operational  availability  of  each  Space 
Station  system  and  of  the  Space  Station  as  an  entity  for  the 
smallest  possible  expenditure  of  resources.  The  preferred 
alternative  in  each  of  the  functional  categories  was  the 
alternative  that  provided  the  most  effective  support  from  the 
most  realistic  combination  of  resources. 

LI  INTEGRATED  LOGISTICS  SDPPORT  (ILS)  PLANNING  AND 
MANAGEMENT 

The  primary  ILS  alternatives  concern  the  approach  to  be  taken 
in  management  structure.  Is  the  most  effective  management 
centralized,  distributed  across  performing  organizations,  or 
allocated  functionally  to  different  management  levels?  Our 
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analysis  showed  that  either  of  the  two  extremes  is 
disfunctional  and  that  an  appropriate  allocation  of  functions 
across  management  levels  and  performing  organizations  provides 
the  most  effective  results.  We  also  concluded  that  the  Phase 
C/D  effort  should  consist  of  highly  centralized  policy 
formulation  and  management  of  logistics  planning  across  all 
Work  Packages  with  a migration  of  logistics  support 
implementation  to  the  launch  site  occurring  as  the  program 
moves  through  the  assembly /checkout  phase  into  on-orbit/  ground 
supported  operations. 

During  mature  operations/  central  policy  formulation  and 
strategic  planning  should  take  place  at  Level  A/the  Program 
Office.  The  Headquarters  function  of  Level  A is  responsible  for 
broad  policy  guidance.  The  Program  Office  is  responsible  for 
central  tactical  planning  and  policy  implementation  guidance. 
Implementation  planning  and  execution  is  performed  on-site  at 
the  operations  center  by  people  involved  with  event  flows. 
Controls  over  execution  of  support  operations  are  extended  by 
the  Program  Office  to  the  operating  levels  in  the  form  of 
standards,  procedures,  and  specifications  to  promote  optimum 
Space  Station  performance  and  safety,  with  minimum  redundant 
efforts  and  unnecessary  expenditure  of  resources,  i.e., 
through  an  optimum  support  posture. 

Realistically,  none  of  these  three  levels  of  ILS  management 
works  alone.  Each  works  with  and  through  the  others,  striving 
to  accomplish  tasks  synergist ically . To  illustrate,  a 
f ive-to-thirty-year  strategic  view  of  Space  Station  Integrated 
Logistics  Support  (ILS)  developed  through  Level  A/The  Program 
Office  Program  Management  would  be  used  as  the  blueprint  for 
year-to-year  tactical  planning;  which  in  turn  sets  the  broad 
guidelines  for  implementation  planning  and  the  subsequent 
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execution  of  event  plans  and  flows.  Upon  completion  of  a plan 
segment , feedback  by  ILS  element  among  levels  permits  status 
quo  continuance  or  adjustments  in  future  plans  and  support 
efforts  at  each  level.  With  new  baselines  established  from  the 
feedback,  reappraisal  and  adjustment,  the  logistics  management 
process  comes  full  circle. 

L2  MAINTENANCE  SCHEDPLING 

L2A  ORBITAL  HARDWARE  SOPPORTED  ON  ORBIT 

The  logistics  subpanel  examined  five  alternate  scenarios  for 
scheduling  on-orbit  maintenance  of  flight  hardware: 
continuous,  periodic,  dry-dock,  fly-in,  and  hybrid.  A schema 
of  periodically  scheduled  maintenance  events  is  realistic  in 
combination  with  the  minimum  necessary,  continuously  scheduled 
maintenance.  Occasionally,  scheduled  and  opportunistic  inspec- 
tions may  uncover  a need  to  "deactivate"  station  elements  for 
major  repairs  on  structures  and/or  system  segments.  Major 
modifications  might  be  accomplished  in  a similar  mode.  A 
minimum  of  necessary  station  keeping  functions  would  be  carried 
out  during  these  "dry  dock"  periods.  Such  downtime  must  be 
viewed  as  essential,  rehabilitation/enhancement  activity. 
Therefore,  emphasis  must  be  on  ensuring  necessary  resource 
availability  at  the  start  of  dry-dock  or  fly-in  to  minimize 
downtime  while  optimizing  planned  task  accomplishment.  To 
facilitate  maximum  crew  work  on  mission  objectives,  a fly-in 
maintenance  team  concept  could  be  the  ideal,  if  the 
state-of-the-design  and  manufacturing  arts  could  support  it 
through  extremely  high  mean-time-between-failures  and  easy 
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maintenance*  Realistically,  however,  such  teams  would  be 
required  so  frequently  to  support  systems  with  currently 
expected  reliabilities  that  this  concept  is  now  economically 
untenable.  With  technological  evolution  leading  to  orders  of 
magnitude  improvements  in  systems  reliabilities  and 
maintainability,  however,  the  fly-in  maintenance  team  mode 
could  become  a viable  concept. 

A positive,  necessary  step  in  an  evolutionary  direction  of 
operating  condition  monitoring  is  Phase  C development  of  a 
performance  and  maintenance  database/ information  management/ 
trend  analysis  system,  developed  and  implemented  during  and 
after  Phase  D.  With  the  resulting  trends  to  guide  the  program, 
evolution  can  efficiently  lead  to  higher  and  higher  equipment 
reliabilities  and  proportionately  decreasing  on-orbit  mainte- 
nance requirements. 

L2B/C  ORBITAL  HARDWARE  AND  GROUND  SUPPORT  EQDIPMENT 
SOPPORTED  ON  THE  GRODND 

While  a continuous  maintenance  program  is  desirable  for 
workload  smoothing,  periodic  requirements  must  be  added. 
Therefore,  a hybrid  maintenance  management  plan  is  recommended 
which  combines  continuous  and  periodic  scheduling.  A pure 
"on-demand"  maintenance  scheduling  approach  for  orbital 
hardware  and  ground  support  equipment  is  ill-advised  due  to  a 
higher  risk  of  equipment  damage  and/or  personnel  injury  at 
times  of  on-orbit  equipment  and  ground  support  equipment 
failure.  Also,  on-demand  maintenance  spikes  would  be 
accentuated  by  linkage  to  launch  and  recovery  periods,  i.e., 
reparable  returning  from  orbit  would  saturate  the  maintenance 
capacity,  and  ground  support  equipment  needing  repairs  during 
prelaunch,  post-launch  and  recovery  periods  would  similarly 
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cause  activity  peaks  and  inactivity  valleys*  This  would  cause 
increased  maintenance  expenses  for  unplanned  maintenance  setup 
costs  and  inefficient  use  of  maintenance  personnel . A 
reasonable  effort  should  be  made  to  smooth  out  such  require-* 
ments  to  optimize  maintenance  resources  allocations  for  ground 
support  of  orbital  equipment  and  ground  support  equipment. 

L3A  ON-ORBIT  MAINTENANCE  EXECDTION 

Five  alternatives  were  examined:  1)  repair  in  place;  2)  remove 

the  failed  ORU,  repair  it,  and  reinstall  it  (a  viable  option 
for  non-mission  essential,  nonhazardous  item  failures);  3) 
remove,  install  a serviceable  spare  and  repair  the  malfunction- 
ing unit  off-line  on-orbit;  4)  remove,  install  serviceable 
spare  and  return  the  malfunctioning  unit  to  Earth  for  repair  on 
the  ground;  and  5)  a hybrid  combining  all  of  the  above.  The 
hybrid  approach  is  appropriate  so  that  the  maintenance 
execution  concept  varies  depending  upon  ORD  or  SRD  support- 
ability  characteristics.  The  Phase  C/D  Logistics  Support 
Analysis  will  be  rigorously  conducted  to  determine  the  overall 
best  maintenance  execution  option  for  each  item. 

Obviously,  at  least  some  on-orbit  repair  capability  appears 
logical  from  American  and  Russian  manned  space  flight 
experience  to  date.  Frequently-failing  items  will  have  to  be 
repaired  or  spares  will  have  to  be  positioned  on  orbit.  A pool 
of  spares  is  desirable  for  critical /frequent  failure  items  to 
minimize  the  time  equipment  is  unavailable  to  perform  a needed 
function.  Some  items  may  require  spares  to  be  positioned 
on-orbit  as  well  as  a capability  to  repair  them  on-orbit. 

Other  items  failing  less  frequently  may  lend  themselves  to 
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on-orbit  or  to  ground  repair.  In  such  instances,  logistics 
support  analysis  (LSA)  related  trade  studies  will  show  mission, 
economic,  and  efficiency  benefits  of  chosen  options.  Trade 
studies  will  be  based  upon  factors  such  as  unit  cost,  repair 
frequency,  repair  resources  cost,  unit  weight  (extrapolated  to 
cost-to-orbit-and-return) , mission  criticality,  and 
reparability  (ease  of  repair).  These  early,  predictive  data 
will  then  be  refined  as  significant  quantities  of  on-orbit  and 
ground  maintenance  and  on-orbit  systems  performance  data  become 
available  for  further  analysis.  Changes  in  maintenance 
execution  modes  will  be  reasonable  to  continue  to  improve 
efficiencies  of  performing  on-orbit  systems  maintenance. 

L3B  ON-GRODND  MAINTENANCE  EXECUTION 

The  following  modes  were  examined  for  earthside  maintenance 
execution  for  both  orbital  and  ground  support  equipment:  1) 

repair  in  place;  2)  remove  the  failed  ORU,  repair  it,  and 
reinstall  it  ( non-essential /noncritical  ORUs);  3)  remove, 
install  a serviceable  spare,  and  repair  the  failed  item 
on-line,  or  discard,  if  it  is  beyond  economical  repair 
(reparables  can  be  fixed  or  discarded  at  government  and/or 
vendor  locations);  and  4)  remove,  install  a serviceable  spare, 
and  repair  the  failed  item  off-line,  or  discard,  if  it  is 
beyond  economical  repair;  5)  remove,  repair  off  site,  and 
replace,  6)  a realistic  combination  or  hybrid  of  the  above 
implementation  modes,  depending  on  each  item's  characteristics. 

Again,  a combination  of  modes  is  preferred  depending  upon 
equipment/ item  characteristics.  Each  type  of  equipment  will  be 
subjected  to  LSA,  and  a plan  for  its  maintenance  tailored  to 
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its  characteristics.  Systems  must  be  designed  during  Phase  C/D 
to  provide  optimal  maintenance  and  supportability . 

L4  DSER  APTONOMY  AND  INTERNATIONAL  PARTICIPATION 


The  Logistics  Subpanel  looked  at  degrees  of  user  autonomy 
possible,  from  self-sufficiency  to  total  NASA  support,  in  order 
to  derive  desired  support  approaches  for  the  range  of  0.  S.  and 
non-D.  S.  users.  Regardless  of  points  of  origin,  users' 
maintenance  facilities,  technical  data,  supply  support, 
transportation,  and  other  ILS  system  interfaces  must  be 
compatible  with  the  NASA  Space  Station  logistics  system.  We 
selected  a position  in  which  NASA  negotiates  with  the  user  for 
support  to  be  provided  by  the  user  and  support  to  be  provided 
by  the  NASA  logistics  system.  Precise  definition  of  what  the 
support  entails  is  a part  of  the  negotiation  process.  For 
example,  the  user  may  provide  on-orbit  operations  and 
maintenance  requirements  for  his  systems  and  equipment,  and 
NASA  may  provide  associated  procedures,  communications  with 
ground  stations,  and  a standard  technical  data  display. 

Storage,  office  and  maintenance  facilities,  and  on-ground 
maintenance  of  selected  on-orbit  and  ground  support  equipment 
can  be  negotiated  on  a case-by-case  basis,  if  the  user  desires 
NASA  support.  Resupply  and  return  may  be  provided  partially  or 
entirely  by  NASA.  Space  Station  systems  familiarization 
training,  however,  must  be  performed  under  NASA  auspices  for 
NASA  and  user  personnel . NASA  Space  Station  cadre  personnel 
should  attend  user  familiarization  training  on  user  systems  and 
equipment,  and  user  personnel  should  similarly  learn  Space 
Station  systems,  to  facilitate  operational  responses. 


L5  TRANSPORTATION  TO  ORBIT 


Though  choice  of  earth-to-orbit  and  orbit-to-Space  Station 
vehicles  is  not  a logistics  decision,  logistics  requirements 
are  pertinent  to  those  vehicle  designers  and  decision-makers. 
Crucial  logistics  factors  include  initial  on-orbit  spares, 
repair  materials,  tools  and  equipment,  and  maintenance/ 
servicing  consumables  plus  subsequent  resupply  and 
return  manifests  of  logistics  items,  for  the  Space  Station  and 
vehicles  to  be  maintained/ serviced  on-orbit.  The  JPL  cost 
model,  MESSOC,  provides  a key  tool  for  management  application 
in  defining  the  logistics  requirements,  and,  therefore,  space 
transportation  vehicle/manifest  needs. 

A combination  of  STS  and  ELV  launch  support  appears  to  be  the 
most  practical  combination  from  the  logistics  perspective. 

With  ELV  support,  the  capacity  for  transporting  logistics  cargo 
weight  and  volume  is  expanded,  and  the  cost  per  mass  unit  is 
decreased.  Support  provided  by  foreign  launch  vehicles  is 
dependent  upon  the  development  of  these  vehicles  by  foreign 
users  of  the  Space  Station  and  coordination  with  NASA 
operations. 

L6  EVOLUTION 

The  alternatives  for  Space  Station  evolution  implementation 
range  from  continuous  incremental  changes  to  block 
modifications,  i.e.,  mods,  for  step  function  improvements  in 
systems  capability.  The  approach  taken  has  dramatic 
implications  for  logistics  support.  A constantly  changing  Space 
Station  systems  configuration  requires  the  constant  revision  of 
logistics  support  analysis,  continuing  investments  in  initial 
spares  and  the  documentation  and  equipment  to  repair  them,  and 
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the  continual  updating  of  training  material  and  operational 
procedures  to  accommodate  the  revised  system  configuration* 
Block  changes,  on  the  other  hand,  afford  the  opportunity  for 
synergistic  planning,  scheduling  and  execution  and  consolidate 
the  configuration  changes  into  manageable  groups. 


Our  analysis  pointed  out  that  block  mods  should  predominate 
over  continuous  design  changes,  though  there  will  be  a need  for 
both.  Incremental  changes  between  block  modes  should  be 

limited  to  those  associated  with  safety  of  station  equipment 
and  personnel . The  urge  to  improve  system  performance  or 
upgrade  to  overcome  minor  shortfalls  in  predicted  performance 
should  be  avoided  in  favor  of  a stable  Space  Station  systems 
configuration  primarily  changed  through  block  mods  that  all 
operational  elements  can  use  in  planning  for  long-term  support. 

L7  ORIGINAL  EQOIPMENT  MANOFACTORER  (OEM)  SUPPORT  STRATEGY 

Over  the  planned  thirty  year  Space  Station  life,  what  role  or 
roles  should  OEMs  play?  The  answer  depends  partially  upon  the 
expected  length  of  useful  component  life  and  reliability,  i.e., 
numbers  of  failures  during  the  life  of  an  OEM  item.  An  item's 
life  should  be  planned  from  initial  installation  through  its 
final  use,  including  its  support.  For  many  items,  predicted 
reliabilities  are  calculated  with  sufficient  certainty  to  be  a 
valid  basis  for  lifetime  spares  acquisition.  For  some  items, 
initial  spares  should  be  bought  on  less  certain  reliability 
calculations  and  follow-on  spares  procurement  can  be  made  on 
actual  usage  factors.  For  a highly  reliable  item,  initial 
spares  can  be  purchased  for  the  program's  life  on  an  insurance 
basis  and  with  no  retention  of  vendor  support.  In  any  case. 
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OEMs  should  not  be  counted  on  beyond  initial  spares 
procurement,  due  to  the  vagaries  of  time  and  economics.  If 
follow-on  spare  buys  are  expected  to  be  necessary,  we  should 
purchase  a complete  reprocurement  data  package  i.e..  Level  III 
drawings  ( "as-built" ) and  engineering  descriptions  of 
sufficient  detail  and  clarity  to  permit  bidders  to  accurately 
estimate  manufacturing  costs  upon  which  proposals  can  be  based. 
One  should  always  guard  against  re-identified  items,  having  the 
true  manufacturer  for  all  items  as  a contractual,  auditable 
requirement.  Op-front  purchasing  of  reprocurement  data  is 
cheaper,  usually  by  two-to-three  times,  than  subsequent 
purchases  of  this  data.  This  significant  cost  differential 
occurs  when  reverse  engineering  is  necessary,  after  original 
drawings  and  data  are  lost.  "If  in  doubt,  buy  the  datal"  is  a 
cost-effective  motto.  Both  follow-on  procurement  and  "dual 
vendor  sourcing”  of  frequently  used  spares  are  cheaper,  if 
reprocurement  of  as-built  data  or  data  rights  are  purchased 
during  acquisition. 

The  role  of  OEMs  also  depends  upon  the  extent  to  which  NASA 
intends  to  perform  the  management  function  for  Space  Station 
spares,  or  to  allow  contractors  to  continue  to  manage  the  items 
they  have  produced.  NASA  should  take  over  the  management  of 
these  items  from  the  point  of  initial  procurement  to  allow 
standardization  of  data  required  from  contractors  as  well  as 
integrated  data  base  design  for  configuration  management, 
historical  tracking  and  requirements  projections.  This 
management  will  also  reduce  unnecessary  procurements  and  costly 
modifications  because  item  modifications  will  be  performed  only 
with  NASA  approval /direction  and  procurement  quantities  will  be 
determined  by  NASA  controlled  systems. 
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3.4  WHITE  PAPERS 


3.4.1  Space  Station  Line  Items  Estimate 

RAYMOND  L.  NORMAN  JR. 

APRIL  3,  1987 

The  following  projections  for  the  number  of  line  items 
anticipated  in  the  Space  Station  inventory  have  been  derived 
through  several  estimating  techniques. 

Space  Station  Operations  Task  Force  Estimate: 

The  first  estimate  of  the  range  of  inventory  line  items  is  one 
derived  through  deliberations  of  experienced  logistics 
professionals  and  the  use  of  a simple  questionnaire  to  Work 
Package  and  other  respondents  who  represent  potential  users  of 
the  SS  inventory  system. 

Work  Package  Estimates 

The  WP  contacts  are  indicated  in  Table  3-9.  These  personnel 
represent  a portion  of  the  SS  Integrated  Logistics  Working 
Group  as  it  existed  in  November  '86  to  March  '87.  These 
contacts  are  responsible  for  the  logistics  function  and 
represent  an  extensive  background  in  the  field  as  the 
Government /user  and  in  some  cases  years  of  industry  experience 
as  well. 
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8PACB  8TATION  OPERATIONS  TASK  FORCE 
range  op  inventory  ESTIMATES  FOR  2010  A 
(LINE  ITEMS  X 1000} 


Common  GSE 


/ 


Common  GSE  was  not  included  in  the  first  iteration  of  this 
estimate.  A non-additive  number  is  given  as  a rough  order 
estimate.  These  numbers  represent  the  best  guess  of  the  KSC  SS 
GSE  point  of  contact  (A.  Anderson) . It  is  believed  that  10%  of 
the  forecasted  $1B  will  become  officially  labeled  "common"  and 
managed  by  KSC.  The  question  remains  from  the  operational 
logistics  organization's  perspective  and  more  properly  from  the 
Program  Office  policy  standpoint” .. .will  there  be  an  Item 
Manager  or  Commodity  Manager  for  this  GSE?”  A policy 
recommendation  is  suggested  that  there  be  an  item  manager 
concept  established  at  KSC  today  for  this  future  equipment  and 
that  a coordination/memo  of  understanding  be  promulgated 
between  the  other  centers  anticipating  the  use  of  the  common 
GSE. 

International  Participants 

No  official  interface  with  the  international  participants  has 
been  initiated  on  this  subject.  The  LeRC  representative  was 
used  as  a sounding  board  for  these  projections.  However,  the 
projections  themselves  were  based  on  Spacelab  experience  for 
JPN  and  ESA.  The  STS  RMS  experience  was  used  for  the  Canadian 
projection. 

Co-orbiting  Platforms 

The  COP  projections  are  based  on  a 50%  relation  with  a more 
complicated  WP;  e.g.  WPl. 
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DOD 


We  believe  that  there  will  be  a significant  DOD  impact  in  the 
outyears.  However,  under  todays  DOD  posture,  such  a large 
projection  does  not  fit  with  public  information.  Should  the  SS 
become  a more  viable  DOD  platform  for  certain  experiments  then 
this  number  would  grow.  The  DOD  representative  indicated  a 
high  estimate  of  60-75K  line  items. 

Experimenter /Principle  Investigator 

There  undoubtedly  will  be  special  cases  were  Pis  will  want  and 
NASA  will  agree  to  stock  store  and  issue  unique  items  for  use. 

A simple  example  of  this  is  a very  high  purity  gas  or  unique 
gas;  e.g.  argon,  which  will  be  needed  for  a PI  while  he  is 
here.  Since  there  is  either  a long  procurement  time  or 
difficulty  in  locating  sources  of  these  lab  quality  resources 
there  will  be  a requirement  for  continuous  stocking  of  a 
limited  but  unique  inventory.  This  inventory  will  be  replaced 
with  different  lines  as  the  nature  of  the  experiments  change. 

Industry 

Just  as  there  will  be  a need  for  unique  PI  items  of  supply, 
industry  will  also  want  uniques  material.  The  mechanisms  for 
reimbursements  of  these  items  to  the  Government  will  be  covered 
in  Program  Implementation  Plans  or  other  agreements. 

Independent  Estimate 

A separate  rough  order  of  magnitude  line  item  projection  was 
independently  made  by  Boeing  Company  representatives. 

(Mr.  Douglas  Ballander,  BAC,  working  on  NAS  10-11238,  867-7430) 
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These  representatives  suggested  that  for  SS  alone  there  would 
be  4408  repairable  ORUs  which  would  require  six  SRUs  per  ORU  to 
be  stocked  and  there  would  be  36.5  unique  pieceparts  per  SRU. 
This  arithmetic  projection  is 


Number  of  ORUs  ........  4,408 

X 6 SRU /ORU  26,484 

X 36.5  parts/SRU 965,352 

Subtotal 996,208 

X Stockage  Factor  30% 


For  a grand  total  of  298,862.  A 4.7%  variance  is  determined 
when  compared  with  the  313,000  line  items  projected  with  the 
SSOTF  logistics.  Subpane]^ projects  that  these  estimates  are 
for  the  number  of  line  items  only.  It  expresses-  our  belief  as 
to  the  RANGE  of  inventory.  It  does  not  describe  the  DEPTH.  We 
believe  that  the  depth  will  be  somewhat  more  than  other 
programs  due  to  the  thirty-year  life  time. 

3.4.2  Maintenance  of  A Complex,  Distributed  System  - LPS 

LORENZ  G.  SIMPKINS 
CCMS  MAINTENANCE  SECTION 
KENNEDY  SPACE  CENTER,  FLORIDA 
MARCH  5,  1987 


Background 

The  Launch  Processing  System  (LPS),  which  was  first  installed 
in  1977,  comprises  three  major  subsystems;  the  Checkout, 
Control  and  Monitor  Subsystem  (CCMS),  Central  Data  Subsystem 
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(CDS),  and  Record  and  Playback  Subsystem  (RPS)  which  support 
the  Space  Transportation  System  (STS)  pre/post-flight 
maintenance  and  checkout,  prelaunch  testing,  and  launch 
operations  at  KSC  and  VAFB.  The  LPS  operations  concept 
involves  automated  checkout  and  launch  procedures,  processing 
of  significant  "change”  data,  and  on-line  test  data  analysis. 

LPS  contains  numerous  simple  and  complex,  analog,  digital  and 
hybrid  electronic  and  electromechanical  devices  (e.g. 
computers,  peripherals.  Line  Replaceable  Units  (LRUs)  and  Shop 
Replaceable  Units  (SRUs)).  The  elements  of  LPS  are  maintained 
in  a classical  manner  as  described  in  one  of  the  following 
three  categories: 

Organizational  Level 

Maintenance  performed  on  vehicle  subsystems  and  related 
support  equipment  in  direct  support  of  the  turnaround 
flow.  It  includes  scheduled  and  unscheduled  maintenance 
actions  required  to  inspect,  service,  calibrate,  replace, 
repair  and  modify  in  place,  and  reverify  (sub)  systems  and 
associated-  components. 

Intermediate  Level 

Maintenance  that  is  performed  in  direct  support  of 
organizational  level  maintenance  and  involves  disposition, 
repair,  service,  modification,  calibration,  and 
verification  of  items  removed  during  organizational 
maintenance.  Automatic  Test  Equipment,  bench  setups  and 
Minimum  System  Configurations  are  used  in  this  level  of 
maintenance. 
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Depot  Level 


Maintenance  that  is  performed  by  designated  maintenance 
sources  (e.g.,  manufacturers,  DSAF  air  logistics  centers, 
NASA  centers,  etc.).  It  normally  consists  of  maintenance 
that  required  test  equipment,  facilities,  or  skills  which 
are  not  economically  available  to  the  intermediate  level 
(e.g.,  repairing  modifying,  overhauling,  reclaiming,  or 
rebuilding  parts,  assemblies,  subassemblies,  components 
and  items,  manufacturing  of  unavailable  parts  and 
providing  technical  assistance  to  the  organizational  and 
intermediate  levels. 

Routine  organizational  level  maintenance  includes  scheduled 
preventive  maintenance  routines  and  corrective  maintenance 
required  to  restore  systems  and  equipment  to  an  operational 
status.  Routine  Organizational  Level  Maintenance  is  performed 
by  maintenance  personnel  assigned  to  each  set/subset  of  CCMS 
equipment.  Corrective  maintenance  requires  problem  isolation 
to  the  LRO  level,  removal  and  replacement  with  a verified 
spare,  and  system  retest.  Selected  troubleshooting  and  problem 
isolation  below  the  LRO  level  is  performed,  when  justified,  by 
technical  and/or  operational  requirements. 

Hardware  Interface  Modules  (HIMs)  located  in  the  LC39  areas 
require  special  consideration  due  to  the  diversified  locations 
and  multiple  set  configurations  possible.  Organizational  level 
maintenance  for  HIMs  is  consolidated  and  implemented  as  a 
separate  group.  A mobile  crew  utilizes  dedicated 
radio-equipped  vehicles  to  provide  maintenance  and  operational 
support  as  required. 
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Logistics  and  intermediate  level  maintenance  support  is 
conducted  from  two  areas.  The  Intermediate  Level  Maintenance 
Facility  (ILMF),  located  in  the  Central  Instrumentation 
Facility  (CIF)  at  KSC,  provides  Intermediate  and  Depot  level 
maintenance  for  all  LPS  equipment,  equipment  fabrication  and 
modification,  and  on-call  maintenance  functions.  MSC  12 
provides  Logistics  support  to  the  ILMF  and  coordination  with 
MSC  34,  which  supports  the  LC39  areas. 

The  ILMF  is  a designated  R&QA  Hardware  Dispositioning  Area 
( HDA ) . LROs  received  at  the  ILMF,  with  the  required  paperwork, 
are  logged  into  the  Production  Tracking  System  and 
dispositioned  per  Source,  Maintenance  and  Recoverability  (SMR) 
Codes.  Barcodes  are  affixed  to  the  paperwork  and  to  the 
LRO/SRU  if  not  already  attached. 

Designated  LRUs,  utilized  in  classified  operations,  are  tested, 
repaired,  and  verified  in  a secure  area.  The  secure  Minimum 
Peripheral  Test  Set  (SMPTS)  provides  a secure  area  for 
maintaining  "hot  spares”  for  use  within  any  control  room,  and 
an  area  for  off-line  maintenance  of  failed  peripherals. 
Intermediate  level  maintenance  on  equipment,  unique  to  secure 
areas,  is  performed  in  this  area,  including  color-change 
procedures  on  LROs  leaving  the  secure  areas.  In  addition, 
selected  Intermediate  level  maintenance  on  other  equipment  is 
performed  as  required.  Maintenance  data  collection  and  work 
control,  in  the  SMPTS,  are  the  same  as  in  unsecured  areas. 


SRO  maintenance  is  performed  in  direct  support  of  LRU 
maintenance  in  the  ILMF  with  the  primary  objective  of  LRO 


turnaround  back  to  usable  spares.  It  includes  dispositioning, 
bench  calibration,  troubleshooting,  repair  and  verification. 

LRU  and  SRU,  maintenance  requirements  are  documented  and 
included  in  the  appropriate  IDMM/IDMMSS.  Repairable  SRUs, 
requiring  separate  testing  and  verification,  are  acted  on  in 
the  same  manner  as  an  LRU.  A separate  work  order  is  opened  for 
each  action  on  an  LRU  or  SRU. 

Over  the  years,  the  decision  to  be  self  sufficient  in 
Maintenance  and  Logistics  Support  has  proven  to  be  the  best 
choice  for  a long  term  program.  Many  Original  Equipment 
Manufacturers  (OEM)  are  either  out  of  business  or  no  longer 
support  the  product.  Expertise  and  documentation  are  gone  or 
unusable.  Due  to  the  above  reasons,  LPS  Maintenance  has 
assumed  more  and  more,  not  only,  the  Intermediate  Level 
Maintenance  role  but  also  that  of  Depot  level  maintenance. 

To  compensate  for  expertise  loss,  both  by  the  OEMs  and  by  our 
SPC,  we  are  making  extensive  use  of  Automated  Test  Equipment 
(ATE)  and  in  the  future.  Artificial  Intelligence  (AI)  systems 
to  capture  the  experts  knowledge.  Mandatory  documentation  has 
been  a requirement  through  out  our  maintenance  processes. 

In  Work  and  The  Future 

We  are  currently  developing  a position  on  the  use  of  ATE  for 
Shuttle  LRUs.  The  use  of  ATE  for  testing  will  allow  one  type 
of  machine  to  do  testing  of  multiple  types  of  LRUs  thus 
eliminating  the  costly  process  of  replacing  obsolete  OEM  test 
fixtures.  The  same  critical  factors  of  expertise, 
documentation  and  repair  costs  are  again  the  drivers  for  this 
decision. 
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In  future  systems,  NASA  has  to  acknowledge  and  fund  the 
inclusion  of  Integrated  Diagnostics,  Testability  and 
Maintainability  at  the  inception  of  a new  project.  It  is  not 
enough  to  build  a highly  reliable  or  redundant  system  to 
accomplish  its  assigned  task.  Systems  still  fail  sometime 
during  their  useful  life  and  we,  the  Maintainers  must  determine 
the  cause  and  repair  the  LRU/SRO  or  resolve  the  cause  to  a 
solution.  When  one  does  a cost  analysis  of  up  front  costs 
(est.  40%)  for  testability  versus  life  cycle  costs  of 
maintenance  support  at  all  levels,  it  becomes  very  clear  that 
it  is  far  better  to  include  our  needs  up  front. 

Recommendations  for  New  Systems 

- Specify  and  Purchase  all  documentation 

- Specify  all  the  elements  that  make  up  Integrated 
Diagnostics  and  Testability 

Plan  for  the  assumption  of  the  Maintenance  of  the 
system  - use  OEM  until  you  have  established  an  in-house 
capability 

- Develop  test  systems  with  both  ATE  and  AI  concepts  in 
order  to  capture  knowledge/expertise 

- Provision  lifetime  spares  during  the  system 
manufacturing  stage  to  improve  supply,  testing  and 
reduce  cost 

Do  a good  job  of  planning  and  budgeting  at  the  earliest 
part  of  system  conception 
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Summary 


Maintenance  of  sophisticated  systems  require  intelligent 
planning  at  conception,  NASA  must  begin  making  that  commitment. 


3.4.3  A Review  Of  Air  Force  Reconnaissance  Programs 

E.D.  KERSEY  JR. 

MAJ.  L.P.  WOOLARO 
APRIL  7,  1987 

At  the  suggestion  of  senior  NASA  management,  members  of  the  the 
panel  visited  the  Headquarters  of  the  Strategic  Air  Command 
(SAC) and  reviewed  the  current  approach  to  logistics  acquisition 
and  support  for  several  types  of  reconnaissance  aircraft.  The 
intent  was  to  examine  the  techniques  applied  to  small  fleet 
sizes  and  to  look  for  parallels  that  might  be  applied  to  the 
Space  Station  Program. 

The  reconnaissance  aircraft  divide  into  two  types,  those  that 
are  modified  versions  of  commercial  aircraft  and  those 
specially  designed  for  unique  missions.  The  approach  to 
acquisition  and  logistics  support  varies  significantly  for  the 
two  types.  The  modified  aircraft  are  acquired  through  the 
normal  Department  of  Defense  acquisition  process.  The  logistics 
support  for  these  aircraft  draws  heavily  on  the  established  Air 
Force  Depot  Maintenance  System  with  mission  peculiar  equipment 
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support  handled  on  a case  by  case  basis.  In  general,  the 
special  design  aircraft  were  not  acquired  by  the  Air  Force  but 
were  assigned  to  the  Air  Force  later  in  the  operating  lifetime 
of  the  aircraft.  As  a result,  the  approach  to  long  term 
logistics  was  not  predicated  on  having  a world-wide  operating 
base  for  support.  By  the  time  the  aircraft  were  assigned  to  the 
Air  Force,  the  pattern  of  total  support  by  the  development 
contractor  was  established.  The  final  mitigating  factor  is  the 
Department  of  Defense  requirement  to  have  an  organic  (in-house) 
front  line  support  capability  in  time  of  hostilities. 

The  large  depot  system  of  support  and  the  unique  nature  of  some 
aspects  of  the  reconnaissance  mission  combine  to  make 
comparisons  with  the  Space  Station  difficult.  There  were, 
however,  some  very  valuable  lessons  learned  which  are 
applicable  to  the  Space  Station  and  if  incorporated  in  the 
acquisition  and  design  activities  will  result  in  cost  savings 
and  enhancements  in  support. 

DSE  OF  STANDARD  HARDWARE . SOFTWARE  AND  FIRMWARE 

The  use  of  standard  state-of-the-art  hardware  was  strongly 
advised.  There  is  a substantial  penalty  in  cost  and 
supportability  associated  with  "exotic"  hardware.  In  addition, 
a list  of  standard  hardware  was  recommended.  The  Air  Force  has 
experienced  multiple  design  agents  for  equipment  and  the 
resulting  duplication  of  inventory  and  support  assets  that 
results  from  each  designer  having  the  freedom  to  specify  his 
favorite  piece  of  gear.  As  a result,  they  have  developed  a 
lists  of  equipment  already  in  the  inventory.  The  designer  of  a 
new  system  must  use  the  equipment  already  in  the  inventory  or 
justify  new  items  as  mission  essential. 


The  application  of  this  approach  to  the  Space  Station  would 
require  the  focused  management  of  hardware , software  and 
firmware  design.  The  Air  Force  experience  indicates,  however, 
that  there  is  a substantial  savings  in  the  magnitude  of  the 
resulting  support  assets  required  which  will  reduce  logistics 
cost  and  reduce  the  scope  of  the  configuration  management  job. 
The  proposal  to  centrally  manage  the  acquisition  of  common  GSE 
would  thus  appear  to  have  great  merit.  The  thrust  for 
program-wide  commonality  and  standardization  should  be 
vigorously  pursued  to  optimize  supportability  and  reduce 
operating  costs. 

DESIGN  APPROACHES  DO  MAKE  A DIFFERENCE 

The  variations  in  supportability  across  the  reconnaissance 
aircraft  types  are  significant  and  result  from  the  differences 
in  design  approach.  The  ratio  of  maintenance  man-hours  to  system 
operating  man-hours  varied  by  a factor  of  ten  and  was  a factor 
of  a hundred,  minimum,  larger  than  the  current  estimates  for 
the  Space  Station.  The  message  is  very  clear 1 You  get  what  you 
design  fori  The  current  Space  Station  maintenance  man-hour 
allocations  call  for  an  improvement  of  two  orders  of  magnitude 
in  reliability  and  or  maintainability (R&M)  over  that 
experienced  by  the  reconnaissance  aircraft.  The  requirement  for 
close  attention  to  (R&M)  during  the  design  cannot  be  over 
emphasized.  In  addition  it  will  be  imperative  that  the  (R&M) 
design  requirements  be  uniformly  applied  across  the  Work 
Packages  if  a consistent  support  posture  is  to  be  achieved. 

BUILT  IN  TEST  EQDIPMENT  (BITE) 

One  of  the  maintenance  man-hour  reduction  techniques  to  be 
applied  in  the  Space  Station  Program  is  the  use  of  built  in 
test  equipment  (BITE).  This  will  minimize  the  time  a crewperson 
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must  spend  in  determining  the  cause  of  failure  in  a piece  of 
equipment  and  if  the  replacement  ORO  is  functioning  properly. 
The  Air  Force  has  experienced  reliability  problems  in  BITE 
which  have  resulted  in  higher  than  predicted  repair  costs.  The 
key  issue  is  who  pays  when  the  BITE  says  you  have  a failure, 
the  ORU  is  subsequently  examined  by  the  manufacturer  and  he 
says  there  is  nothing  wrong  and  ships  it  back.  The  program  has 
thus  incurred  the  cost  of  removal,  replacement  and  shipping, 
which  in  our  case  can  be  from  orbit.  The  suggestion  from  the 
Air  Force  is  that  if  the  BITE  gives  a false  indication  of 
failure  which  results  in  a remove  and  replace  action,  that  the 
manufacturer  be  contractually  responsible  for  his  own  cost  and 
that  the  fee  structure  should  meaningfully  recognize  this 
action  as  poor  performance. 

BDSINESS  STRATEGY 

It  was  suggested  that  the  Space  Station  Program  will  need  a 
long  term  business  strategy  that  is  supportive  of  the  logistics 
support  strategy.  The  contractual  and  management  mechanisms  for 
coordinating  the  residual  support  from  prime  contractors , the 
operations  contractors  and  the  original  equipment  manufacturers 
continuing  to  support  the  program  need  to  be  well  thought  out 
and  provide  incentives  for  each  party  to  perform  well.  The 
vagaries  of  the  NASA  budget  process  need  to  be  anticipated  to 
smooth  variations  in  support  posture. 

DATA  ACQUISITION 

Emphatically,  SAC  systems  support  experts  stated  the  require- 
ment to  buy  all  technical /engineering  data  or  data  rights 
during  full-scale  engineering  and  development.  The  data  should 
be  deliverable  in  government  specified  format(s),  validated  by 
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the  development  contractors  and  verified  under  government 
auspices  as  to  technical  accuracy,  completeness  and  usability 
before  final  government  acceptance.  Drawings  and  schematics 
must  be  suitable  for  use  in  component/assembly  reprocurement, 
i.e..  Level  III  drawings,  "as  built,”  complete  in  technical 
detail  and  fully  legible,  so  that  a non-OEM  vendor  can  produce 
the  required  item  without  re-engineering  or  reverse  engineer- 
ing. This  level  of  technical  integrity  is  also  required  in  the 
technical  documentation  to  be  used  for  maintaining  hardware, 
software  and  firmware,  to  eliminate  or  at  least  reduce  to  the 
absolute  minimum  any  program  dependency  on  OEMS  for  technical 
guidance  during  the  operational  phase.  Acquiring  only  data  . 
rights,  in  lieu  of  actual  data,  must  be  reserved  for  only  those 
relatively  few  specific  items  for  which  there  is  no  foreseen 
need  to  subsequently  support,  modify  or  replace  in  kind.  In 
such  cases,  having  purchased  the  rights  to 

technical /engineering  data  ensures  future  data  acquisition 
capability  in  the  event  of  unexpected  need. 

This  concept  is  much  preferred  over  the  idea  of  acquiring 
technical /engineering  data  piece  meal  when  needed  over  the 
program  life*  In  the  case  of  the  Space  Station,  not  having 
items  of  data  ready  to  apply  when  needed  could  be  safety  or 
mission  critical,  even  disastrous,  and  undoubtedly  much  more 
expensive  than  up-front  acquisition. 

MAINTENANCE  DATA  GATHERING 


It  is  clear  from  the  Air  Force  experience  that  there  is  a 
dubious  payback  to  current  systems  support  posture  for  the  cost 
of  maintenance  data  gathering.  It  is  clear  that  the  design  of 
new  aircraft  does  benefit  from  the  knowledge  gained  through 
maintenance  data  gathering  on  operating  systems.  It  would 
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appear  that  the  Space  Shuttle  program  missed  a golden 
opportunity  to  provide  an  experience  base  for  Space  Station 
designers  when  the  development  of  a maintenance  data  gathering 
system  was  not  pursued. 

The  suggestion  offered  was  that  regardless  of  the  approach 
taken  the  system  needs  to  be  automated,  user  friendly  and  that 
it  should  provide  an  immediate  information  payback  to  the 
current  system  maintainer  in  order  to  gain  his  support  for  data 
input  discipline. 

OPERATIONS  CONTRACTOR  APPROACH 

After  discussing  the  approaches  taken  by  the  Air  Force  in 
providing  logistics  support  for  the  various  aircraft  and 
missions  involved  in  reconnaissance  several  conclusions  have 
been  reached.  If  the  Space  Station  Program  elects  the  option  of 
a downstream  operations  center  contractor  with  expertise  to 
support  sustaining  engineering  as  well  as  the  broad  based 
logistics  support  the  program  will  require,  we  must  decide  and 
implement  an  appropriate  operational  strategy  during  the 
Phase  C/D  period.  The  operations  contractor  should  be  part  of 
the  design  process.  If  we  do  not  involve  them  up  front,  we  will 
have  to  use  a combination  of  operations  and  development 
contractor  expertise  managed  by  the  operations  civil  service 
center  personnel.  This  approach  would  require  a migration  of 
management  responsibility  from  the  development  centers  to  the 
operations  center,  a task  we  have  not  accomplished  well  in  the 
past. 

The  other  conclusion  reached  is  that  the  particular  approach 
selected,  while  important,  is  less  important  than  the  timing  of 
the  decision.  The  compelling  need  is  to  select  a support 
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approach  early  in  the  design  process  and  to  insure  that  the 
design  process  includes  supportability  decisions  that  are 
consistent  with  the  support  approach  selected.  In  the  case  of 
Space  Station,  the  design  discipline  must  extend  across  all 
four  of  the  Work  Packages  and  include  all  elements  if  a unified 
support  posture  is  to  be  achieved. 

Clearly,  the  person  who  should  be  the  most  concerned  about  this 
issue  today  is  the  person  who  will  be  accountable  for  Space 
Station  operational  performance.  That  person  needs  to  be 
identified  immediately  and  given  the  wherewithal  to  deal  with 
these  issues. 
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4.0  SUSTAINING  ENGINEERING/CONFIGURATION  MANAGEMENT 
4.1  INTRODUCTION 

Sustaining  Engineering  and  Configuration  Management  are  critical 
activities  required  during  the  Space  Station  mature  operations 
phase.  These  two  activities  are  closely  interrelated  and  will 
be  required  and  conducted  during  all  phases  of  the  mature  opera- 
tions: (1)  ground  processing  operations,  (2)  on-orbit  flight 

operations,  and  (3)  upload  and  download  flight  operations.  For 
the  purpose  of  this  report,  mature  operations  for  sustaining 
engineering/configuration  management  is  defined  as  the  phase 
after  development  and  after  initial  operations  when  major  rede- 
sign activities  have  stabilized. 

As  a general  definition,  sustaining  engineering  is  maintaining  a 
design  that  fulfills  original  design  intent  and  is  compatible 
with  intended  operational  use.  Problems  are  resolved  to  keep  the 
hardware/ software  systems  in  an  operational  status.-  Operational 
performance  is  enhanced  through  product  improvement  redesign  for 
more  cost  effective  and  efficient  operations.  Approved  changes 
in  design  and  requirements  are  incorporated  as  part  of  system 
evolution.  Sustaining  engineering  excludes  major  upgrading  of 
existing  systems  or  the  acquisition  of  new  systems  if  more  than 
incidental  research  and  development  is  required,  but  supports  new 
development  to  gain  the  expertise  necessary  to  operationally 
sustain  new  systems. 

Configuration  management  is  defined  as  the  discipline  of  applying 
technical  and  administrative  direction  and  surveillance  to 
identify  and  document  items  under  configuration  control,  to 
control  changes  to  these  items,  to  record  change  processing  and 
implementation  status  (configuration  status  accounting),  and  to 
verify  compliance  with  requirements  (auditing). 
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4.2  SUMMARY 


Sustaining  engineering  is  an  assigned  role  of  the  Space  Station 
Program  and  is  an  ongoing  operational  function  performed  under 
the  Integrated  Operations  Management  system  of  the  Space  Station 
Program.  Two  basic  levels  of  management  for  the  sustaining 
engineering  efforts  are  identified:  1)  the  tactical  planning 
level  and  2)  the  execution  level.  Tactical  level  engineering 
integration  and  configuration  control  is  performed  as  a central- 
ized organizational  function  at  the  NASA  Headquarters  level.  The 
executional  management  functions  are  performed  at  the  NASA 
operation  centers  receiving  direction  and  technical  requirements 
from  the  tactical  management  system  located  at  NASA  Headquarters. 

4.2.1  Flight  Systems 

The  executional  responsibilities  for  sustaining  engineering  of 
the  Space  Station  flight  systems  and  interfaces  are  centralized 
at  the  launch  center.  The  centralized  function  performs  the 
responsibilities  for  supporting  the  flight  systems  during  ground 
processing,  up load /down load  operation,  and  on-orbit  operations. 
Considering  that  the  on-orbit  operations  are  "remoted"  to  the 
ground  and  that  the  other  operations  are  primarily  occurring  at 
the  launch  center,  locating  the  sustaining  engineering  responsi- 
bilities at  the  launch  center  has  considerable  merit.  A signifi- 
cant exception  to  the  foregoing  concept  is  to  provide  for  a 
separate  organizational  concept  at  a separate  flight  operations 
center  for  the  sustaining  functions  (except  commonality)  of  the 
Space  Station  platforms  (except  commonality)  pending  the 
programmatic  concept  in  organizationally  separating  the  platform 
operations  from  the  manned  operations  of  the  Space  Station. 
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Internationals  and  users  perform  their  own  sustaining  engineering 
functions  within  established  Space  Station  program  policies, 
guidelines,  and  criteria  which  are  initiated  at  the  strategic 
level  and  further  defined  at  the  tactical  and  execution  levels. 
Safety  issues  and  interfaces  are  controlled  by  the  Space  Station 
Program.  For  users  a payload  integration  organization  (user 
integration)  is  established  under  Space  Station  operations  to 
coordinate  the  engineering  integration  and  interfacing  function 
between  users  and  the  Space  Station  sustaining  engineering 
organizations  at  the  tactical  and  execution  levels.  The  techni- 
cal analysis  of  compatibility  with  the  Space  Station  is  performed 
as  an  integral  function  of  the  centralized  sustaining  engineering 
task  at  the  launch  center. 

The  Space  Station  consists  of  flight  elements  designed  and 
developed  by  NASA,  Internationals,  and  users.  Each  of  these 
elements  will  be  responsible  for  the  sustaining  engineering  of 
the  hardware  and  software  provided  for  that  element  of  space 
station  operations.  NASA  has  the  overall  responsibility  of 
performing  the  analysis  to  ensure  the  compatibility  of  us- 
er/International  designs  and  performance.  Each  user  will  be 
required  to  design  to  a standard  Space  Station  user  interface. 

The  user/internationals  must  establish  compatible  management 
procedures  which  will  assist  NASA  in  accomplishing  Space  Station 
integration.  All  elements  must  work  with  and  participate  in 
established  methods  of  controlling  hardware/software  interfaces, 
i.e.  Interface  Control  Documents  (ICD's).  The  Space  Station 
engineering  integration  function  is  a NASA  sustaining  engineering 
activity  that  will  integrate  all  Space  Station  hardware/software 
design  into  an  integrated  operational  station.  The  engineering 
activity  will  encompass  system  analyses,  (e.g.,  hazards,  thermal 
loads,  stress,  mass,  dynamics...),  resource  allocation  between 
International  elements  and  NASA  elements,  and  NASA  safety  certi- 
fication of  engineering  changes  (this  includes  all  user  hard- 
ware/software modifications  and  International  modifications). 
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An  established  method  of  controlling  hardware  and  software  design 
interfaces  will  be  used  by  NASA  during  mature  operations.  Where 
design  interface  exists  between  the  Space  Station  flight  systems 
and  an  International  module.  Interface  Control  Documents  (ICD'S) 
will  document  this  design.  The  ICD's  will  be  baselined  jointly 
by  the  affected  Internationals  and  the  Space  Station.  All 
proposed  changes  to  these  ICD's  will  be  jointly  processed  and 
jointly  approved  by  the  Space  Station  operations  and  Internation- 
als involved.  Interface  Revision  Notices  (IRN's)  will  be  used  to 
document  proposed  and  approved  changes  to  joint 

NASA/ International /users  ICD's.  These  ICD's  will  show  standard 
interfaces  to  which  the  Space  Station  is  designed  and  which  the 
International s/users  will  be  expected  to  meet.  Exceptions  to  the 
standard  interfaces  will  require  interface  changes  which,  as 
approved  by  the  Space  Station  operations,  will  require  peculiar 
ICD's  between  the  Space  Station  and  user  instrument.  These 
peculiar  interfaces  must  be  designed  for  removal  and  return  to 
the  standard  interface  design  upon  mission  completion  of  the 
affected  user  instruments . Both  the  standard  Space  Station/user 
ICD's  and  the  peculiar  Space  Station/user  ICD's  will  be  baselined 
and  controlled  using  established  ICD  change  processing  methods. 

4.2.2  Space  Station  Dedicated  Support  Systems 

The  Space  Station  support  systems  receive  tactical  direction  and 
technical  requirements  from  the  NASA  Headquarters  level  and  the 
execution  responsibilities  are  performed  at  the  operations 
centers.  The  distributed  support  systems  which  are  located  and 
utilized  across  the  NASA  centers  are  assigned  to  the  lead  opera- 
tions center  to  perform  the  sustaining  engineering.  The  sustain- 
ing engineering  for  commonality  in  support  systems  is  also 
assigned  to  the  lead  operations  center.  Unique  systems  dedicated 
to  ground  processing  or  flight  operations  are  assigned  to  the 
launch  center  and  flight  operations  centers,  respectively. 
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4.2.3  Multi-Program  Support  System 


The  multi-program  support  systems  perform  their  own  sustaining 
engineering  outside  the  Space  Station  Program.  The  multi-program 
support  systems  include  NASA  programs  such  as:  transportation 

systems  including  NSTS,  satellites  such  as  TDRSS,  NASA  institu- 
tional systems  ....  The  support  of  these  systems  to  the  Space 
Station  Program  are  initially  agreed  to  at  the  strategic  level 
and  further  interface  relationships  are  established  at  the 
tactical  and  execution  levels.  Normally  the  Space  Station 
Program  performs  within  the  standards  and  criteria  of  these 
support  systems  to  a joint  agreement  to  preclude  unilateral 
changes  impacting  the  Space  Station  Program.  NASA  Space  Station 
operations  will  perform  the  technical  coordination  and  integra- 
tion between  the  users/internationals  and  the  multi-program 
support  systems. 

4.2.4  Engineering  Change  Processing 

Inherent  in  sustaining  engineering  responsibilities  is  the  change 
processing  methodology.  The  methodology  can  be  divided  into 
functions  and  interfaces.  The  flight  element  change  processing 
methodology  requires  engineering  change  definition,  a review  and 
evaluation  process,  change  approval,  and  the  actual  change 
implementation  plan.  The  NASA  configuration  management  system 
will  provide  for  an  engineering  change  identification,  evalua- 
tion, approval  and  implementation  system  which  will  control  all 
changes  to  the  Space  Station  and  the  Space  Station  dedicated 
support  systems  during  the  operational  phase.  Internationals  and 
users  of  the  Space  Station  must  have  internal  management  systems 
which  are  similar  with  NASA's  change  prpcessing  methodology  and 
compatible  where  interface  controls  are  necessary.  The  primary 
configuration  control  responsibility  is  at  NASA  Headquarters; 
delegated  authority  to  the  operations  centers  is  a NASA  Headquar- 
ters option. 
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Space  Station  change  methodology  and  rationale  for  Space  Station 
changes  during  mature  operations  is: 

o To  minimize  all  engineering  changes.  During  mature 
operations  the  only  authorized  changes  will  be  those 
approved  for  design  improvement,  i.e.  to  correct  a 
component /system  failure  and  minor  enhancements  to 
improve  operational  efficiency.  Major  upgrades  and 
evolution/growth  designs  are  considered  as  separate 
development  programs  and  are  only  operationally  sustained 
after  turnover  to  mature  operations. 

o To  permit  design  of  engineering  changes  only  to  those 
elements  who  have  been  assigned  sustaining  engineering 
responsibilities  as  authorized  by  the  Space  Station 
Program. 

o To  approve  all  changes  to  the  hardware /software  configu- 
ration which  must  be  incorporated  on  flight  systems  and 
interfaces . 

o To  flight  certify  all  changes,  including  those  required 
by  Internationals/users,  which  must  be  integrated  into 
Space  Station  hardware /software  either  on-orbit  or  prior 
to  launch.  Users  will  be  encouraged  to  have  design 
maturity  prior  to  experiment  delivery  and  integration 
into  Space  Station  elements/systems. 

4.2.5  Real-Time  Support 

Real-time  support  will  be  provided  on  an  on-call  basis  to  monitor 
critical  operations  and  to  perform  failure  analysis  of  critically 
failed  components / systems . For  on-orbit  and  up/down  load  opera- 
tions, a small  scale  integration  function  will  exist 
around-the-clock  to  coordinate  the  on-call  support  as  required, 
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to  track  problems,  integrate  problem  resolution,  and  to  identify 
areas  where  engineering  support  is  required. 

4.2.6  Transition  Phase 

A concerted  plan  between  Space  Station  operation  and  development 
organizations  must  define  transition  requirements  for  the  mature 
operations  phase.  This  plan  must  be  established  early  in  the 
development  phase  to  ensure  an  efficient  turnover  to  mature 
operations.  The  recommended  concept  is  to  have  operational 
representatives  involved  during  the  early  development  phase  and 
an  engineering  core  in-place  approximately  three  years  prior  to 
turnover.  The  turnover  will  occur  in  increments  and  on  a 
system-by-system  basis  depending  on  design  maturity  and  complexi- 
ty. A decision  milestone  prior  to  the  three  years  is  necessary 
to  determine  the  turnover  status  and  establish  the  turnover  date. 
This  is  applicable  to  complex  systems;  the  time  is  shorter  for 
less  complex  systems  or  when  turnovers  have  minimal  impacts  in 
transitioning  to  mature  operations.  Design  maturity  during 
initial  operations  will  determine  turnover  date  and,  hence, 
mature  operations. 

4.3  FUNCTIONAL  DESCRIPTIONS 

Configuration  management  and  sustaining  engineering  activities 
are  interrelated  and  support  each  other  in  the  sustaining  opera- 
tions of  the  space  station.  Figure  4-1  shows  the  basic  functions 
of  Sustaining  Engineering/Configuration  Management  and  typical 
inputs  and  products.  This  section  of  the  report  will  further 
describe  the  functions  of  sustaining  engineering  and  configura- 
tion management. 
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EXTERNAL  INTERFACES 


4.3.1  Sustaining  Engineering  Functional  Descriptions 


In  discussing  sustaining  engineering  functional  descriptions,  a 
top  level  listing  includes  the  following: 

1.  Planning  and  Management 

2.  Systems  Analysis 

3.  Design  Engineering 

4.  Engineering  Integration  and  Verification 

5 . Documentation 

Each  of  these  five  functional  descriptions  are  outlined  in 
Appendix  E and  discussed  as  follows: 

Planning  and  Management 

The  functions  of  planning  and  management  for  sustaining  engineer- 
ing address  the  cost,  schedule,  and  performance  impact  for 
accomplishing  sustaining  engineering  activities,  for  selecting 
one  approach  for  an  activity,  and  then  following  the  results  of 
this  activity  on  a periodic  basis.  These  functions  cover  budget 
management,  contract  management,  and  resources  management  (cost 
and  manpower).  Management  functions  for  Advanced  Technology 
Programs  when  assigned  to  the  Space  Station  operations  will  be 
included.  The  functions  will  provide  for  Space  Station 
evolution/growth  management  wherein  the  sustaining  engineering 
organization  must  plan,  manage,  and  implement  an  approach  for 
Space  Station  design  changes  and  methods  for  permitting  a 
systematic  growth  in  the  design  of  the  Space  Station.  Some 
outputs  from  the  planning  and  management  functions  are  plans, 
schedules,  budget  requests,  evaluation  of  proposed  MOU  changes, 
contract  changes,  and  management  directives.  These  functions 
will  continue  the  use  of  management  information  systems,  which 
were  initiated  during  the  Space  Station  development  phase. 
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Systems  Analysis 


Systems  analysis  is  a key  sustaining  engineering  function.  A 
primary  portion  of  sustaining  engineering  analyses  will  be  turned 
over  by  the  Space  Station  Work  Package  contractors  to  the  opera- 
tions sustaining  engineering  organization.  System  analyses  will 
document  the  results  of  the  development  phase  and  describe  in 
total  the  Space  Station  design  including  Space  Station  unique 
ground  support  equipment  and  models,  test  beds  and  simulators. 
Also  turned  over  will  be  engineering  drawings  and  parts  lists 
which  completely  describe  the  hardware  and  software  configura- 
tions of  end  items  provided  during  the  development  phase.  This 
data  base  will  be  provided  to  the  operations  sustaining  engineer- 
ing organization  at  the  start  of  mature  operations.  Examples  of 
analyses  in  this  data  base  are: 

o Systems  Performance  Analyses 
o Mass  Properties  Analyses 
o Failure  Mode  and  Effects  Analyses 
o Stress  Analyses 
o Thermal  Analyses 
o Vibration  Analyses 
o EMI  Analyses 
o Sneak  Circuit  Analyses 
o Hazards  Analyses 
o Safety  Analyses 

Any  proposed  configuration  change  to  controlled  end-items  must  be 
assessed  for  impacts  to  program  costs  and  schedules,  to  feasi- 
bility, availability,  commonality,  maintainability,  operability, 
and  safety  aspects  of  the  Space  Station. 
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An  important  system  analysis  function  of  sustaining  engineering 
is  flight  certification  engineering  analysis.  During  mature 
operations,  every  design  change  to  the  Space  Station  flight 
systems  must  be  flight  certified  by  NASA.  In  most  cases,  the 
sustaining  engineering  organization  will,  given  a proposed  change 
design  concept,  conduct  an  engineering  design  analysis  as  to  the 
change's  overall  affect  on  the  Space  Station  if  that  change  is 
incorporated.  The  analysis  would  be  updated  throughout  the 
design  cycle  of  the  change  until  the  change  modification  kit  is 
verified  and  accepted  for  change  incorporation.  At  the  accep- 
tance review  for  that  change,  the  updated  flight  certification 
analysis  is  part  of  the  review.  Safety  issues  of  a change  are 

reviewed  during  the  preliminary  or  critical  design  reviews.  If  a 

/ 

safety  concern  had  existed  for  this  change,  it  would  be  eliminat- 
ed or  resolved  during  the  change  design  finalization.  If  not, 
the  change  would  be  disapproved.'  Ideally,  the  change  should  be 
disapproved  prior  to  detailed  design  in  order  to  save  engineering 
design  effort.  For  this  reason,  safety  considerations  must  be 
considered  early  in  the  design  change  process.  The  flight 
certification  process  directly  involves  the  Internationals  and 
the  users.  Any  user  must  have  his  experiment  flight  certified  by 
the  NASA  sustaining  engineering  organization  prior  to  flight. 

User  documentation  published  by  NASA  will  define  these  require- 
ments. In  a like  manner,  Internationals  must  have  their  flight 
incorporated  design  changes  certified  by  NASA  sustaining 
engineering.  Changes  incorporated  prior  to  launch  will  be  safety 
and  flight  certified  by  NASA  as  a part  of  certification  of  the 
complete  International  module  or  end  item  (to  be  accomplished 
during  the  Space  Station  development  phase).  During  mature 
operations,  flight  certification  will  be  accomplished  on  an 
individual  engineering  change  basis.  The  Space  Station  opera- 
tions organization  will  manage  the  flight  certification  process 
during  the  operational  phase. 


4-11 


The  Space  Station  sustaining  engineering  activity  must  work 
closely  with  the  International's  sustaining  engineering  personnel 
responsible  for  International  Space  Station  hardware  and  soft- 
ware. Interface  Control  Documents  (ICD's)  will  be  used  to 
control  the  design  between  D.S.  provided  hardware  and  Interna- 
tional provided  hardware.  The  International  agency  will  accom- 
plish sustaining  engineering  within  its  management  system  unless 
interface  design  is  affected  or  Space  Station  requirements  such 
as  contamination,  safety,  materials,  ....  are  not  met.  When  a 
nominal  requirement  cannot  be  met,  the  International  sustaining 
engineering  organization  will  submit  a design  waiver  to  the  Space 
Station  requirement  listing  the  proposed  waiver  requirement, 
what  will  be  met  in  lieu  of  existing  design  standards,  and  a 
justification  of  why  the  waived  condition  is  acceptable  for  the 
time  period  listed  in  the  waiver.  Design  improvements  or  problem 
fixes  proposed  by  Internationals  which  do  not  affect  the  above 
criteria  will  be  approved  and  implemented  by  the  International 
except  NASA  will  approve  flight  certification  recommendations 
which  is  required  for  all  design  modifications  to  be  incorporated 
in  the  operational  Space  Station. 

The  Space  Station  sustaining  engineering  function  also  interfaces 
directly  with  many  users  providing  Space  Station  payloads  (exper- 
iments). Users  will  be  required  to  meet  the  requirements  of 
Space  Station  accommodations.  Interfaces  will  include  de- 
sign/performance data  reporting  and  resource  usage  agreements. 

The  users  must  submit  sufficient  payload  data  for  the  Space 
Station  flight  certification  to  the  sustaining  engineering 
organization.  In  some  instances,  the  user  may  request  a change 
to  the  Space  Station  design  to  accommodate  a specific  experiment. 
If  approved,  NASA  sustaining  engineering  and  the  user  must 
coordinate  closely  on  the  interface  analysis  and  design.  Changes 
to  this  design,  must  be  coordinated  and  shall  be  designed  to  be 
returnable  to  the  original  configuration  after  the  experiment 
mission . 
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Design  Engineering 


As  a major  part  of  sustaining  engineering,  design  engineering 
will  perform  conceptual,  preliminary,  and  detailed  design  for 
space  station  flight  hardware/ software  and  associated  ground 
support  equipment.  The  design  engineering  function  will  inherit 
from  the  Space  Station  development  phase  a large  quantity  of 
engineering  data,  such  as,  drawings,  specifications, 
program-level  requirements  documents,  operations  and  maintenance 
documents,  ....  Most  of  this  data  will  be  maintained  by 
sustaining  engineering  throughout  mature  operations  as  changes 
are  approved  to  the  Space  Station  and  ground  support  systems. 
These  data  will  be  revised  accordingly  to  provide  an  up-to-date 
design  configuration.  If  an  evolution/growth  change  is  author- 
ized to  the  Space  Station,  the  design  engineering  data  base  is 
the  initial  baseline  for  the  evolution/growth  design.  The  design 
of  an  evolution/growth  change  is  outside  the  scope  of  operational 
sustaining  engineering  until  the  design  becomes  operational. 

The  design  engineering  function  is  vitally  concerned  with  inter- 
face design.  Interface  design  is  controlled  by  NASA's  system  of 
Interface  Control  Documents  (ICD's).  These  documents  list  the 
interface  design  between  hardware/ software  elements,  and  are 
approved  by  both  interfacing  agencies  responsible  for  the  hard- 
ware or  software.  Once  approved,  ICD'S  cannot  be  changed  unless 
all  approval  parties  agree  to  the  change.  Interface  Revision 
Notices  (IRN's)  are  used  to  document  preliminary  and  finally 
approved  changes  to  ICD's. 

The  preparation  of  modification  kit  instructions  is  a responsi- 
bility of  design  engineering.  For  each  modification  kit,  in- 
structions are  required  to  explain  how  the  change  is  to  be 
incorporated  on-orbit  or  at  the  launch  site.  Instructions  for 
installing  the  modification  kit  detail  parts  in  the  logistics 
carrier  is  included.  Return  parts  and/or  tools  must  be 
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stored/mounted  in  the  logistics  carrier  for  return  to  earth. 
Depending  on  the  complexity  of  the  change,  detailed  design  may  be 
required  for  upload  and  download  of  parts  included  in  the  modifi- 
cation kit.  Test  and  verification  requirements  must  be  included 
in  the  mod  kit  and  test  procedures  for  verifying  that  the  changed 
hardware/ software  is  operating  satisfactorily.  In  summary, 
modification  kit  instructions  integrate  the  engineering  change 
into  one  package  which  totally  and  completely  describes  the 
change,  how  to  verify  the  change,  both  on  the  ground  and  on 
orbit,  and  how  to  install  the  change  (with  flight  procedure 
detail ) . 

Sustaining  engineering  is  concerned  with  component  failures, 
maintainability  analyses,  and  failure  analyses.  All  failures 
must  be  analyzed  and  recurring  control  actions  taken  as  required. 
Failure  analysis  may  determine  that  a design  change  is  required 
or  additional  spares  must  be  procured.  Maintenance  requirements 
could  be  affected  and  must  be  revised  as  required. 

Sustaining  engineering  must  conduct  design  reviews.  The  design 
and  development  of  any  Space  Station  complex  engineering  change 
will  require  accomplishment  of  NASA's  system  of  design  reviews 
from  Preliminary  Design  Review  (PDR),  Critical  Design  Review 
(CDR),  Design  Certification  Review  (DCR)  and  finally.  Flight 
Acceptance  Review  (FAR).  Engineering  changes  may  not  require  all 
of  these  reviews  or  several  changes  can  be  covered  at  a single 
review.  The  intent  of  these  reviews  must  be  covered  during 
engineering  change  design  development  and  acceptance.  Affected 
users  and  Internationals  will  participate  in  these  design  re- 
views. Upon  completion  of  design  for  a change,  and  incorporation 
of  the  change  into  any  flight/ground  subsystem/system,  design 
engineering  will  prepare  revisions  of  the  affected  drawings, 
specifications,  ...  to  an  "as  built"  configuration.  Completion 
notices  of  verification,  installation  and  checkout  will  update 
the  data  bases  indicating  final  closeout  of  a change. 
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If  Space  Station  design  changes  require  test  articles  or  addi- 
tional support  equipment,  a sustaining  engineering  function  is  to 
identify  the  items  and  justify  the  utilization  for  engineering 
change  verification.  Upon  change  approval  these  items  must  be 
designed  and  procured  or  manufactured.  Design  specifications  and 
other  documentation  will  be  supplied  by  sustaining  engineering. 

Engineering  Integration  and  Verification 

Sustaining  engineering  must  closely  integrate  both  systems 
analysis  and  design  engineering.  For  any  proposed  engineering 
change,  engineering  must  be  totally  integrated  to  determine  all 
hardware  and  software  affected  by  the  change.  If  affected, 
design  changes  must  be  made  to  these  items  as  well.  The  inte- 
gration function  must  carefully  review  a proposed  change  and 
determine  if  ground  systems,  transportation  systems,  and  ground 
data  communications,  software  systems,  Internationals, 
users,  ....  are  affected.  Impacts  to  change  all  affected  systems 
must  be  included  and  submitted  in  the  engineering  change  proposal 
for  NASA  approval.  Change  assessments  must  be  obtained  from 
Flight  Operations,  Ground  Processing,  Logistics  and  Safety, 
Reliability  and  Quality  Assurance  (SR&QA). 

Each  proposed  engineering  change^must  be  reviewed  to  determine 
how  it  will  be  verified.  Verification  test  planning  includes 
test  objectives  and  requirements,  evaluation  criteria,  proce- 
dures, test  plans,  training  requirements,  logistics  requirements, 
and  schedules.  Any  hardware  or  software  required  for  verifica- 
tion must  be  identified,  justified,  designed  and  manufactured  or 
procured.  The  manufacturing  and  procurement  functions  must  be 
supported  by  sustaining  engineers  who  are  familiar  with  the 
engineering  change.  Any  software  change  must  be  verified  and 
validated  in  the  hardware/ software  integration  facility.  Inte- 
grated test  plans  and  requirements  will  be  developed  for 
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prelaunch  verification  the  final  installation,  and  checkout  of 
the  modification. 

All  sustaining  engineering  functions  will  be  required  to  support 
both  flight  and  ground  operations  to  resolve  anomalies  or  to 
monitor  systems  performance  or  test  results.  If  a critical 
operation  or  test  is  to  be  conducted,  real-time  sustaining 
engineering  support  will  be  provided  as  required  for  operations. 
Routine  sustaining  engineering  support  will  be  provided  by 
engineering  integration  functions  which  will  coordinate  engineer- 
ing expertise  as  required.  For  mature  operations,  a high  level 
of  real-time  engineering  support  will  not  be  required  during 
routine  operations. 

Documentation 


There  will  be  a large  amount  of  documentation  required  to  accom- 
plish Space  Station  sustaining  engineering.  Requirements  docu- 
ments, ICD's,  and  engineering  drawings  must  be  kept  up-to-date  in 
an  electronic  data  base.  These  data  will  be  provided  to  mature 
operations  by  organizations  involved  in  the  development  phase. 
Configuration  status  and  accounting  reports  will  be  a part  of 
sustaining  engineering  documentation.  Mass  Property  Reports, 
Performance  and  Trend  Prediction  Reports  and  Engineering  Analyses 
will  be  required  and  kept  up-to-date.  Flight  certification 
reports  and  the  latest  status  of  this  activity  will  be  main- 
tained. Other  documentation  will  include  commonality  items  and 
the  status  of  their  development.  SR&QA  Documentation  will 
include  Critical  Items  Lists,  Failure  Mode  & Effects  Analyses, 
ALERTS,  Safety  Assurance  Analyses,  Hazards  Analyses,  and  Inspec- 
tion Reports.  The  required  documentation  electronic  data  base 
will  be  obtained  and/or  prepared,  and  maintained  in  order  to 
accomplish  Space  Station  sustaining  engineering.  To  the  maximum 
extent  possible  this  documentation  will  be  computerized  and  made 
available  to  all  Internationals  and  users.  Data  access  to  the 
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Internationals'  and  users'  data  bases  will  also  be  made  avail- 
able. It  is  imperative  for  mature  operations  of  the  Space 
Station,  that  the  development  phase  documentation  be  transferred 
for  maintenance  and  control  by  the  operations  organizations. 
Electronically,  an  overall  goal  is  to  minimize  the  required  Space 
Station  program  documentation  under  maintenance  and  control . The 
operations  sustaining  engineering  function  will  continue  to 
minimize  the  active  program  documentation  required  for  Space 
Station  sustaining  engineering  throughout  the  mature  operations. 
Historical  documentation  will  be  archived  and  accessible  when 
required. 

4.3.2  Configuration  Management  Functional  Descriptions 

Configuration  management  is  a support  function  that  provides 
management  discipline  and  surveillance  to  the  space  station 
configuration.  For  Space  Station  mature  operations  an  effective 
management  and  communications  system  for  controlling  and  docu- 
menting changes  is  required  to  ensure  continued  operations 
support.  Configuration  management  utilizes  sustaining  engineer- 
ing to  accomplish  its  objectives. 

For  each  proposed  engineering  change,  configuration  management 
determines  the  organizations  and  elements  which  are  affected  by 
the  change.  Sustaining  engineering  must  determine  what  subsys- 
tems are  affected  and  what  disciplines  are  affected,  such  as 
verification,  software,  reliability,  maintainability,  ....  A 
major  area  of  responsibility  is  document  maintenance.  The 
control  documents  which  configuration  management  has  under 
baseline  control  are  engineering  documents,  such  as,  specifica- 
tion, ICD's,  and  engineering  analyses.  Configuration  management 
must  ensure  that  the  Space  Station  engineering  data  base  (engi- 
neering drawings  and  parts  lists)  is  maintained  accurately  by 
sustaining  engineering. 
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Configuration  management  has  four  functions:  1)  configuration 

identification,  2)  configuration  control,  3)  configuration 
verification  (auditing),  and  4)  accounting.  Each  of  these 
functions  is  outlined  in  Appendix  F and  discussed  as  follows. 

Configuration  Identification 

For  Space  Station,  the  identification  of  configuration  end  items 
will  have  been  accomplished  during  the  development  phase  and  will 
be  given  to  mature  operations  organizations.  New  end  items  to  be 
controlled  may  be  added  to  this  list  when  required  and  justified 
as  part  of  an  approved  engineering  change. 

Configuration  Control 

The  configuration  control  function  will  process  proposed  changes 
to  the  Space  Station  and  will  support  systems  designs.  The 
change  control  system  permits  evaluation  of  each  change  by 
affected  organizations  and  provides  for  a final  decision  on  the 
change  when  evaluation  is  complete.  As  changes  are  approved, 
affected  control  documentation  is  also  updated,  and  the  change 
implementing  organization  is  directed  to  accomplish  the  change. 
Real-time  status  of  change  processing  will  be  accomplished  from 
change  request  receipt  to  change  incorporation  in  the  hard- 
ware/software end  item. 

The  approval  of  engineering  changes  is  controlled  by  NASA  by 
delegating  approval  authority  to  the  appropriate  NASA  manager. 

For  example,  the  Space  Station  flight  hardware  and  each  support 
system  will  have  separate  NASA  managers.  These  managers  will 
have  defined  engineering  change  approval  authority.  If  interface 
changes  between  systems  are  proposed,  the  NASA  managers  responsi- 
ble for  both  systems  will  have  joint  change  approval  authority. 
For  changes  affecting  International  or  user  interfaces,  a joint 
change  processing  methodology  will  be  agreed  to  by  the  affected 
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parties  and  this  methodology  will  identify  the  managers  with 
change  approval  authority.  In  a similar  manner,  contractors 
under  contract  to  NASA  will  have  certain  change  approval  authori- 
ty for  hardware /software  assigned  to  their  control.  For  the 
Space  Station  flight  hardware  and  software,  engineering  change 
approval  authority  is  normally  assigned  to  NASA  managers  only. 

Verification  (Auditing) 

Audits  will  be  performed  to  verify  that  the  configuration  manage- 
ment procedures  and  implementation  practices  are  being  followed 
by  the  program  elements  and  organizations.  Reviews  will  be 
conducted  to  assure  that  modifications  and  changes  are  being 
implemented  in  accordance  with  configuration  change  directives 
and  that  the  as-built  configuration  is  identical  to  the 
as-designed  configuration.  Corrective  action  will  be  identified 
and  recommended  to  configuration  management. 

Accounting 

The  configuration  accounting  function  not  only  closes  out  each 
configuration  change,  it  also  updates  each  controlled  document 
affected  by  the  change.  Also,  engineering  release  records  are 
revised  to  show  the  new  configuration  on  the  engineering  drawings 
and  parts  lists.  Configuration  accounting  also  provides  a status 
of  all  change  requests,  control  board  directives,  proposals,  and 
change  dispositions.  Included  in  configuration  accounting  is  the 
status  of  the  modification  kits  and  instructions  required  to 
incorporate  an  approved  change. 

4 . 4 OPERATIONAL  CONCEPTS 

This  section  of  the  report  describes  concepts  for  organization, 
transition  to  mature  operations,  change  processing  methodology, 
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and  selected  special  topics  as  they  relate  to  sustaining  engi- 
neering and  configuration  management. 

4.4.1  Organizational  Concepts 

The  following  concepts  describe  organizational  roles  and  rela- 
tionships for  sustaining  engineering  and  the  controlling  levels 
of  configuration  management  for  mature  operations.  The  opera- 
tions centers  perform  the  execution  functions  and  support  the 
tactical  planning  and  requirement  activities  at  NASA  Headquar- 
ters. Operations  centers  are  inclusive  of  the  launch  center  and 
the  flight  operation  centers  for  manned  space  station,  space 
station  platforms,  and  payload  operations  centers  whether  com- 
bined or  separated  organizationally. 

Sustaining  Engineering 

Figure  4-2  shows  the  basic  organizational  concept  for  sustaining 
engineering. 

Integrated  Space  Station  Operations.  At  a centralized  NASA 
Headquarters  level,  tactical  planning,  budgeting,  and  engineering 
integration  are  performed.  Incremental  manifests  are  defined  and 
engineering  requirements  are  established  to  support  the  forthcom- 
ing increments.  Inputs  from  the  Internationals,  users, 
multi-program  support  systems,  evolution/growth  programs,  and 
from  the  operations  centers  are  assessed  and  integrated  into 
operational  plans  and  requirements  including  approved  configura- 
tion management  requirements  and  directives  affecting  physical 
and  functional  interfaces  to  the  space  station  flight  systems  and 
support  systems  for  all  phases  of  the  mission  increments  (ground 
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SUSTAINING  ENGINEERING  - ORGANIZATION  CONCEPTS 


2 


processing,  upload/download,  and  on-orbit  processes).  An  engi- 
neering analysis  and  assessment  as  to  the  feasibility  and  sup- 
portability  of  the  increment  planning  is  performed  by  the  opera- 
tions centers.  Requirements  to/from  users  are  integrated  and 
coordinated  by  a NASA  Space  Station  Payload  Integration  Organiza- 
tion. 

The  Space  Station  sustaining  engineering  organizations  at  the 
operations  centers  will  accomplish  the  major  functions  of  sus- 
taining engineering  under  the  centralized  management  and  control 
system  at  NASA  Headquarters.  This  provides  a singular  management 
interface  to  the  Internationals  and  to  the  users.  This  also 
provides  a single  approach  to  maintenance  of  the  Space  Station 
engineering  data  base  (EDB)  throughout  mature  operations.  A 
standard  system  will  be  provided  for  processing  engineering 
changes  and  updating  affected  Space  Station  documentation.  The 
operations  centers  provide  the  technical  support  and  analysis 
required  for  the  tactical  planning.  Major  design  changes  to 
Space  Station  hardware /software  are  evaluated  and  approved  at 
this  level  and  are  included  in  the  tactical  planning  for  the 
Space  Station  operation.  The  request  for  major  redesigns  is 
normally  initiated  at  the  operations  centers;  upon  approval,  the 
design  effort  is  assigned  to  the  evolution /growth  design  develop- 
er who  will  proceed  with  the  redesign  under  operations  control. 
Evolution/growth  programs  which  are  strategically  planned  at  the 
Space  Station  Program  level  is  performed  separate  from  the 
integrated  Space  Station  operations;  however,  the  operations 
centers  will  support  these  programs  from  an  operations  perspec- 
tive. 

Space  Station  Flight  Systems  and  Interfaces.  A centralized 
function  responsible  for  the  sustaining  engineering  of  the  flight 
systems  and  its  interfaces  is  defined  at  the  executional  level 
and  is  located  at  the  launch  center.  Staffing  with  sufficient 
engineering  expertise  exists  to  perform  engineering  integration, 
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systems  analysis,  and  design  engineering  to  maintain/sustain  the 
flight  systems  during  ground  processing,  upload/download,  and 
on-orbit  operations. 

The  engineering  integration  functions  are  primarily  "project 
management”  organized  (for  example,  manned  modules,  logistics 
modules,  support  system  interfaces,  international  and  user 
interfaces,  ....)  to  provide  interfacing  and  coordinating  capa- 
bilities to  other  organizational  elements  including  coordination 
of  real-time  support.  Requirements  from  the  tactical  level  at 
Headquarters  are  normally  received  and  coordinated  with  the  other 
sustaining  engineering  organizations. 

System  engineering  to  perform  such  tasks  as  failure  and  perfor- 
mance analysis,  modification  designs,  and  engineering  assessments 
are  organizationally  pooled  and  led  by  sub-system  managers  in 
individual  system  disciplines  (for  example,  flight  software, 
environmental  control  systems,  communications,  structures,  . . 

. ) . In  the  presence  of  evolution/growth  development  for  the 
Space  Station,  major  design  engineering  efforts  will  be  selec- 
tively assigned  to  the  evolution/growth  contractor  but  responsive 
to  Space  Station  operations  control  and  integration;  an  "on-call" 
capability  will  exist  between  sustaining  engineering  and  the 
evolution/growth  activities  for  expertise  and  major  design 
support.  Evolution/growth  engineering  representatives  will  be 
assigned  as  contact  coordinators  to  the  sustaining  engineering 
organization.  "In-house"  design  engineering  will  contain  the 
capability  to  perform  small-scale  modifications  and  enhancements. 

Within  the  Space  Station  Program,  there  exists  unique  flight 
elements  and  systems  which  merit  having  separate  sustaining 
engineering  organizations  (excepting  commonality  and  interfaces). 
Two  significant  examples  are  the  Space  Station  platforms  and  EVA 
systems.  Because  of  their  uniqueness  and  minimal  interfaces. 
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separate  sustaining  engineering  groups  in  these  areas  located  at 
the  corresponding  operations  centers  is  advantageous. 

Development  Design  Engineering.  Evolution/growth  programs  are 
separate  and  functionally  removed  from  the  Integrated  Space 
Station  operations.  To  have  access  to  this  resource  of  expertise 
and  to  develop  the  sustaining  expertise  for  the  evolution/growth 
systems,  a relationship  needs  to  exist  between  development  and 
operations  organizations.  This  interconnected  relationship 
consists  of  two  parts;  1)  evolution/growth  development  and  2) 
design  support  to  Space  Station  operations. 

For  evolution/growth  activities  space  station  operations  will 
support  by  providing  operational  design  perspectives  and  at  the 
same  time  develop  the  necessary  engineering  expertise  to  sustain 
the  evolution/growth  designs  after  they  become  operational.  For 
major  designs  to  sustain  the  Space  Station,  an  "on-call"  capabil- 
ity shall  exist;  for  these  designs  the  developer  shall  be  respon- 
sive to  the  requirements  of  the  design  as  defined  by  Space 
Station  operations. 

The  rationale  for  a separate  organization  is  to  minimize  inter- 
ference with  the  mission  of  Space  Station  sustaining  engineering 
and  vice  versa  for  the  development  programs.  To  control  the 
possible  overlap  between  these  two  organizations,  the  development 
organization  and  the  sustaining  engineering  organization,  special 
design  control  features  would  be  established.  The  control 
features  would  result  in  interfacing  agreements  that  define  the 
interfaces  for  the  organization  responsible  for  the  operational 
design  changes  and  the  organization  responsible  for  development 
hardware /software  design.  Copies  of  released  design  changes 
would  be  provided  via  the  engineering  electronic  data  base  to  the 
development  organization  by  the  sustaining  engineering  organiza- 
tion. The  design  concepts  developed  by  the  development  organiza- 
tion would  be  coordinated  with  the  sustaining  engineers. 
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Additional  agreements  would  be  established  between  these  organ- 
izations to  assure  NASA  that  successful  Space  Station  sustaining 
engineering  and  follow-up  development  activity  would  be  mutually 
compatible  with  mature  operations. 

Soace  Station  Support  Systems.  Space  Station  dedicated  support 
systems  can  be  categorized  as  follows: 

1.  Support  systems  unique  to  flight  operations  (com- 
mand/control stations,  flight  data  processing,  communica- 
tions ) . 

2.  Support  systems,  unique  to  pre/post  flight  operations 
(servicers,  handling  equipment,  test  equipment). 

3.  Distributive  systems  which  reach  across  centers  including 
systems  having  commonality  in  function  and  design, 
(simulators,  trainers,  SSE,  TMIS) 

In  all  three  categories,  the  executional  functions  of  sustaining 
engineering  is  performed  at  the  operations  centers.  Tactical 
planning  and  requirements  are  received  from  NASA  Headquarters. 

For  categories  1 and  2,  the  sustaining  functions  are  performed 
locally  at  the  flight  operations  center(s)  and  the  launch  center, 
respectively. 

For  category  3,  lead  operations  centers  are  assigned  the  respon- 
sibility to  perform  the  sustaining  engineering  functions  for  the 
individual  distributed  systems  and  the  common  designs.  Organiza- 
tionally these  functions  may  be  combined  with  other  sustaining 
engineering  functions  being  performed  at  the  same  operations 
center.  The  sustaining  efforts  for  simulators  and  trainers  which 
are  similar  to  the  flight  systems  maintains  an  engineering 
exchange  with  the  flight  systems  sustaining  engineering  to  retain 
flight-type  configurations. 


4-25 


The  sustaining  engineering  for  SSE  should  be  assigned  to  an 
operations  center  as  a consolidated  function;  field  engineering 
functions  will  be  required  because  of  its  distributive  nature. 
TMIS  can  be  sustained  in  the  same  manner;  however , if  the  concept 
of  TMIS  management  goes  across  other  NASA  programs  then  TMIS  will 
be  sustained  in  a manner  similar  to  other  multi-program  support 
systems . 

Dser  Operations  Support  ( PIO  Functions ) . The  user  operations 
support  role  is  a Payload  Integration  Organization  (PIO)  function 
under  Space  Station  operations  performing  integration  and  coordi- 
nation responsibilities  between  the  Space  Station  and  users  at 
tactical  and  execution  levels.  The  users  perform  sustaining 
engineering  on  their  own  instruments  and  support  systems  within 
operating  envelopes,  standard  ICD's  and  safety  standards  provided 
by  Space  Station  operations  via  PIO  functions.  The  PIO  coordi- 
nates with  the  user  and  acquires  user  design  and  performance  data 
and  ensures  that  the  users  are  within  the  Space  Station  stan- 
dards. Specified  data  is  required  by  Space  Station  sustaining 
engineering  to  maintain  the  overall  Space  Station  configuration 
and  performance.  Space  Station  sustaining  engineering  will 
perform  the  technical  risk  assessment,  design  compatibility 
analysis,  and  flight  certification  review.  If  the  standards  are 
exceeded  or  if  the  user  has  unique  requirements,  the  Space 
Station  sustaining  engineering  function  will  perform  the  neces- 
sary analysis,  assessments,  and  approvals  prior  to  incorporating 
the  unique  requirements . 

International  Operations.  The  Internationals  will  perform 
sustaining  engineering  on  their  hardware/ software  within  operat- 
ing envelopes,  ICD's,  and  safety  standards  established  by  Space 
Station  operations.  The  Internationals  will  also  perform  engi- 
neering integration  functions  with  their  users  and  provide  or 
make  accessible  their  integrated  design/resource  data  to  Space 
Station  operations.  This  data  will  be  utilized  by  Space  Station 


4-26 


sustaining  engineering  to  maintain  the  overall  space  station 
configuration  and  performance.  The  International  sustaining 
function  includes  their  support  systems.  NASA  may  assume  respon- 
sibility for  sustaining  engineering  only  in  cases  of  negotiated 
agreements.  Safety  requirements  will  be  analyzed,  assessed,  and 
approved  by  Space  Station  operations. 

The  interfacing  sustaining  engineering  functions  with  Space 
Station  operations  is  performed  at  the  tactical  and  executional 
levels.  To  perform  this  function,  engineering  integration 
representation  to  support  tactical  planning  and  execution  is 
minimally  required  in  the  U.S. 

Multi-Program  Support  Systems.  Commitments  of  support  are 
normally  agreed  to  at  the  strategic  planning  level  under  the 
Space  Station  program.  Tactical  planning  is  performed  at  the 
Space  Station  operations  level  at  NASA  Headquarters  and  the 
execution  at  the  operation  centers. 

The  multi-program  support  systems  perform  sustaining  engineering 
on  their  own  systems  outside  the  Space  Station  Program.  Safety 
standards  and  standard  ICD's  including  operating  envelopes  are 
provided  to  space  station  operations  by  joint  agreement.  Space 
Station  sustaining  engineering  provides  integrated  engineering 
data  on  design/resources  to  the  multi-program  support  systems. 

The  Space  Station  operational  sustaining  engineering  organization 
will  interface  directly  with  the  other  NASA  Programs.  The 
interface  design  for  hardware  and  software  belonging  to  these 
programs  and  interfacing  with  Space  Station  Program  hardware  and 
software  will  be  documented  on  Interface  Control  Documents 
(ICD's)  and  approved  by  both  interfacing  programs.  This  design 
is  then  kept  under  configuration  control.  Any  proposed  change 
initiated  by  either  program  which  affects  that  design  must  be 
coordinated  with  the  interfacing  program.  If  both  programs 
agree,  each  program  then  implements  the  change  within  their 
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organization  to  jointly  agreed  directives.  If  new  hardware /soft- 
ware is  required  by  any  program  and  an  interface  design  exists 
with  the  Space  Station  Program  hardware /software,  an  ICD  must  be 
baselined  and  controlled  to  document  the  interface  design  for 
both  programs.  Inherent  in  the  ICD  systems,  is  the  requirement 
on  both  organizations  to  annotate  the  ICD  design  shown  on  engi- 
neering drawings  so  that  the  interfacing  program's  concurrence  is 
obtained  prior  to  the  initiator  program  incorporating  that  change 
in  their  hardware  and/or  software. 

Operations . Space  Station  operations  are  defined  as  flight 
operations,  Pre/Post  Flight  Operations,  Logistics,  Information 
Systems,  and  SR&QA. 

The  sustaining  engineering  interfacing  functions  with  operations 
are  described  at  primarily  the  execution  level.  These  functions 
occur  at  the  operations  centers  (flight  operations  center(s)  and 
launch  center). 

Technical  requirements  are  provided  by  sustaining  engineering  for 
implementation  into  operational  procedures.  These  include  test 
and  checkout,  maintenance,  and  verification  requirements.  For 
mature  operations,  these  requirements  are  normally  limited  to 
approved  changes  associated  with  modifications  and  enhancements. 

A feedback  system  from  operations  includes  the  data  which  veri- 
fies that  the  requirements  have  been  met  or  completed. 

Real-time  support  by  sustaining  engineering  is  provided  on  an 
"on-call"  basis  for  critical  operations  or  failure  analysis 
support.  The  engineering  integration  function  coordinates  this 
support  with  operations.  Failure  reports  are  provided  by  opera- 
tions to  the  sustaining  engineering  organizations  who  performs 
the  analysis,  integrate  the  problem  resolution,  and  recommend  to 
operations  the  integrated  solution. 
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The  upload/download  operations  are  complex  and  requires  consider- 
able mass  properties  analysis,  flight  dynamics  assessment  and 
configuration  definition  which  is  supported  by  configuration 
management  and  sustaining  engineering  functions.  The  standards, 
criteria,  and  requirement  envelopes  will  be  provided  by  sustain- 
ing engineering  via  computer  aided  analysis  and  inputted  by 
operations  using  approved  manifest  and  flight  certified  hardware 
data.  When  using  a fully  automated  system  for  mature  operations, 
the  computer  models  and  programs  are  then  maintained  and  con- 
trolled by  sustaining  engineering  and  configuration  management. 
The  integrated  payload  data,  mass  properties  and  configuration, 
are  then  provided  to  the  transportation  systems  such  as  STS  or 
ELV's  for  their  overall  compatibility  analysis. 

Configuration  Management 

A major  activity  required  for  the  Space  Station  operational  phase 
is  configuration  management.  This  activity  works  closely  with 
the  sustaining  engineering  organization  but  is  separately  man- 
aged. A key  function  of  configuration  management  will  consist  of 
engineering  change  processing.  In  order  to  control  these  changes 
and  to  assure  acceptable  approval  of  these  changes,  NASA  will 
establish  configuration  change  approval  levels.  These  levels  are 
listed  in  Figure  4-3.  The  control  levels  listed  in  the  first 
column  of  Figure  4-3  are  generally  relatable  to  NASA  organiza- 
tional levels. 

Configuration  Control  Boards.  Levels  I and  II  relate  to  Space 
Station  organizational  levels  A and  the  Program  Office  (or 
equivalent).  Level  III  is  the  resident  manager's  level  at  the 
operations  centers;  for  flight  systems,  this  is  delegated  as  an 
option  from  Level  II.  Level  IV  is  the  project  element  or  con- 
tractor control  level  and  may  be  delegated  by  Level  III  to  the 
sustaining  engineering  organization  at  the  operations  centers. 
Each  level  documents  the  criteria  which  an  engineering  change 
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Figure  4-3 

CONFIGUREMENT  MANAGEMENT 
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II.  Integrated  Space  Station  Operations 
o Budget  and  Cost  Allocations 

o Management  Requirements  and  Responsibility  Allocation 
o Design/Performance  Requirements  and  Standards 
o Interface  Requirements 
o SR  and  QA  Requirements 
o Commonality  Requirements 
o Information  System  Requirements 
o Acceptance  and  Certification  Requirements 
o Level  I Requirements  and  Traceability 
o User  Integration  Requirements 
o Integrated  Baseline  Configuration 

III.  Space  Station  Operations  Centers 

o Level  I and  II  Requirements  and  Traceability 
o Specific  Requirements  and  Specifications 

- Design/Performance 
Interfaces  (ICD's) 

Verification 

o Internal  Baseline  Configuration  as  delegated  from 
Level  II 

IV  Project  Element  Operations 

o Level  I,  II,  and  III  Requirements  and  Traceability 
o Detailed  Specifications 
o Engineering  Releases 
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affects.  The  change  must  be  approved  at  that  level.  For  exam- 
ple, changes  affecting  the  international  module  to  Space  Station 
flight  system  interfaces  would  affect  the  level  controls  at  Level 
II  as  shown  on  Figure  4-3.  Therefore  a proposed  change  would  be 
coordinated  with  the  Internationals,  change  impacts  would  be 
developed  and  consolidated,  and  all  the  change  data  would  be 
forwarded  to  Level  II  for  a joint  disposition  with  the  affected 
International.  Again,  referring  to  Figure  4-3,  during  mature 
operations,  it  is  expected  that  Levels  I and  II  will  retain 
approval  authority  for  all  engineering  changes  affecting  the 
Space  Station  flight  systems.  Change  approval  authority  to 
ground  support  systems  hardware/ software  will  be  delegated  to 
Levels  III  and  IV  at  the  various  NASA  operation  centers.  These 
levels  are  usually  the  Program  Manager  at  Level  III  and  Project 
Managers  at  Level  IV.  Ouring  mature  operations,  these  two  levels 
may  be  combined  into  one  level  which  would  be  Level  III  which 
relates  to  Level  C in  the  Space  Station  development  phase.  Each 
approval  level  receives  its  change  approval  authority  from  the 
next  higher  level.  If  a manager  does  not  desire  to  delegate  any 
change  approval  authority  to  the  sub-tier  managers,  then  he  is 
the  approval  authority  for  his  level  and  the  next  lower  level. 
Level  IV  is  the  final  level  which  is  delegated  to  sustaining 
engineering  for  the  Space  Station.  During  mature  operations, 
this  delegation  will  be  for  engineering  drawing  changes  which 
affect  the  drawings,  parts  lists,  and  other  similar 
documentation,  but  does  not  affect  hardware  or  software.  The 
approval  authority  for  hardware /software  changes  will  be  delegat- 
ed to  sustaining  engineering  for  identified  ground  support 
systems,  but  if  the  change  affects  an  external  interface  the 
approval  level  will  be  Level  III  or  higher. 


Another  ground  rule  which  assists  in  understanding  the  control 
levels  is  that  any  level  can  disapprove  a change  which  affects 
the  controls  at  any  other  level.  This  means  a Level  III  Manager 
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can  disapprove  a Level  I change.  The  Level  II  manager,  which 
receives  copies  of  Level  III  control  board  directives,  can  review 
the  disapproval  decision  and  require  additional  justification. 

If  the  Level  II  manager  is  strongly  for  approval , he  may  direct 
that  the  Level  III  manager  approve  the  change.  This  would  rarely 
occur  and  is  mentioned  only  for  clarifying  how  the  system  works. 
If  the  disapproved  change  is  an  interface  change,  and  it  is 
strongly  required  by  the  interfacing  manager,  the  interfacing 
manager  usually  has  the  change  redefined  or  proposes  the  change 
be  implemented  by  another  means.  In  this  case,  a new  change 
request  is  processed  to  the  Level  III  manager  who  disapproved  the 
first  Level  I change.  In  many  cases,  the  rewritten  change  or  the 
new  method  of  implementing  it,  is  sufficient  for  the  manager  to 
accept  the  change  and  approve  it. 

Documentation . A key  function  for  configuration  management 
during  the  operational  phase  is  maintenance  of  the  Space  Station 
Electronic  Engineering  Data  Base  (EDB).  Maintenance  of  the  EDB 
will  primarily  consist  of  keeping  the  following  computerized 
programs  up-to-date: 

Change  Processing  Status  - Records  receipt  of  all  change  re- 
quests, and  tracks  the  status  of  these  requests  through  the 
change  flow  to  CCBD  approval  and  final  contractual  direction. 

Control  Documentation  Record  - Maintains  all  Space  Station 
control  documents,  such  as  specifications,  ICD's,  ACD's  and 
BCD's,  and  released  approved  changes  to  these  documents  by 
releasing  change  pages  which  incorporate  the  document  change. 
Maintains  in  computerized  storage  a baselined  record  of  all 
program  controlled  documents. 

Modification  Kit  Status  - Tracks  the  development  of  mod  kits  from 
CCBD  approval  through  design,  manufacture,  preparation  of  modifi- 
cation kit  for  delivery,  checkout  of  kit  at  launch  site. 
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installation  in  Logistics  Module,  launch,  and  incorporation 
on-orbit,  verification,  and  inspection  of  final  change.  Verifi- 
cation and  installation  completion  notices  will  be  released  and 
distributed  for  each  modification  kit  installation. 

Engineering  Release  Records  - Provides  the  status  of  all  engi- 
neering drawings,  parts  lists,  and  engineering  orders  for  all 
Space  Station  Program  hardware  engineering  drawings.  Prints 
configuration  record  of  each  end  item  at  any  point  in  time. 

Engineering  Drawing  Computerized  File  - This  file  provides  and 
stores  copies  of  all  Space  Station  engineering  drawings.  These 
drawings  are  updated  as  they  are  changed.  These  drawings  may  be 
accessed  by  any  Space  Station  Program  participant  on-the-ground 
or  on-orbit. 

Other  computerized  records  may  be  required,  and  established  on  a 
case-by-case  basis. 

4.4.2  Change  Processing  Methodology 

Configuration  management  requires  the  application  of  good  manage- 
ment practice  to  all  required  actions  from  change  request  through 
change  incorporation.  An  effective  change  processing  methodology 
must  assure: 

o Comprehensive  impact  analysis 
o Control  of  cost  and  schedule  impacts 
o Optimum  implementation 
o Coordinated  implementation 
o Accurate  configuration  records 
o Supportability 
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The  most  visible  and  usually  the  most  criticized  aspect  of  change 
processing  is  configuration  control.  Consequently,  today's 
environment  demands  an  automated  change  processing  system  with  an 
efficient  Configuration  Control  Board  (CCB)  operation. 

The  configuration  management  system  must  provide  for  an  engineer- 
ing change  identification,  evaluation,  approval  and  implementa- 
tion system  which  will  control  all  changes  to  the  Space  Station 
and  the  dedicated  support  systems  during  mature  operations. 
Internationals  and  users  of  the  Space  Station  must  have  internal 
management  systems  which  are  similar  with  NASA's  change  process- 
ing methodology  and  compatible  where  interface  controls  are 
necessary.  Procedural  methods  for  the  overall  change  process 
system  are  required  and  must  be  documented  for  all  participants 
to  adapt  and  function  within  the  proper  standardized  procedures. 

Configuration  Control  Board  (CCB) . The  CCB  is  the  focal  point 
for  program  change  management  and  is  responsible  for  the  total 
assessment  of  change  impact.  It  also  directs  implementation  for 
changes.  Typical  CCB  membership  should  include  sustaining 
engineering,  operations,  SR&QA,  logistics,  program  management, 
configuration  management,  manufacturing,  test,  and  others  as 
required.  The  CCB  membership  should  assure  complete  change 
analysis  and  evaluation  by  all  involved.  All  members  may  not  be 
required  for  every  meeting,  but  there  should  always  be  a core 
group  present.  Alternate  members  should  be  assigned  whenever 
possible.  The  CCB  chairman  makes  the  final  decisions  and  should 
be  either  the  program  manager  or  the  configuration  management 
manager . 

CCB  effectiveness  can  be  maximized  and  meeting  time  minimized  by: 

o Distribution  of  change  requests  and  agenda  prior  to 
meeting 

o Change  impact  analysis  by  each  member  prior  to  meeting 
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Attendance  by  member  or  alternate 
o Availability  of  necessary  technical  documentation 
o Preparation  of  complete  CCB  directive 
o Preparation  and  distribution  of  minutes 
o Preparation  and  distribution  of  change  status  reports 

For  maximum  efficiency  a recorder  is  present  at  each  CCB  meeting. 

Change  impact  analysis  is  the  single  most  important  CCB  function 
because  it  is  the  source  of  data  for  all  .other  activities. 

Faulty  analysis  can  have  wide  ranging  inputs  on  performance, 
cost,  and  schedule.  A comprehensive  impact  analysis  requires 
homework  and  input  by  the  CCB  members.  A preliminary  analysis  by 
engineering  may  be  necessary  prior  to  the  development  of  the 
final  analysis.  The  use  of  analysis  checklists  are  helpful.  The 
results  of  the  analysis  is  documented. 

It  is  the  responsibility  of  the  configuration  management  organ- 
ization to  either  accomplish  or  assure  others  accomplish  the 
following  for  hardware/software  changes: 

o Change  request  documentation 
o Request  processing  and  recording 
o Approval /disapproval 

o Incorporation  in  configuration  documentation 
o Incorporation  in  products 
o Verification  of  incorporation 

The  requirements  and  objectives  of  change  management  are  the  same 
for  hardware  and  software.  However,  the  methods  have  to  change 
because  of  a higher  rate  of  changes  that  can  be  worked  mostly 
internal  to  the  software  organization.  Delegation  may  be 


necessary  to  the  software  organization  under  specified  criteria 
and  control.  A software  member  then  would  be  included  on  the 
CCB. 

Computerized  Data  Systems 

CAD/CAM  and  automation  present  challenges  for  change  management 
because  of  the  real-time  change  capability  and  dispersed  data 
bases.  Timely  change  coordination  and  verification  of  change 
incorporation  becomes  more  difficult.  To  meet  these  challenges 
it  is  necessary  that  CM  be  established  as  the  data  base  control- 
ler with  impound  capability.  Maximum  automation  of  change 
processing,  change  analysis,  and  CCB  operation  should  be  imple- 
mented. Extensive  terminal  coverage  for  CCB  members  and  manage- 
ment should  be  provided.  Computer  aided  inspection/auditing  is 
utilized  to  verify  change  incorporation. 

Change  Integration 

The  typical  flow  for  an  engineering  change  during  mature  opera- 
tions covers  the  elements  participating  in  the  various  functions 
required  to  assure  an  acceptable  processing  of  the  change  from 
receipt  through  final  incorporation.  Figure  4-4  shows  a generic 
function  flow  of  change  processing.  Appendix  G further  describes 
in  detail  the  process  of  changes.  A key  part  of  this  functional 
flow  is  change  integration.  Change  integration  is  a responsibil- 
ity of  configuration  management  with  assistance  from  the  sustain- 
ing engineering  organization.  Change  integration  is  the  activity 
which  totally  and  completely  describes  a proposed  change,  thereby 
identifying  all  hardware  and  software  affected  by  the  change  and 
the  organizations  required  to  implement  the  change  if  it  is 
approved.  When  a change  is  initially  received,  the  configuration 
management  organization  makes  a distribution  to  all  organizations 
affected  by  the  change.  These  organizations  are  listed  on  the 


4-36 


SUSTAINING  ENGINEERING 
GENERIC  FUNCTIONAL  FLOW 

CHANGE  PROCESSING 


• AS-OOUT  DOCUMENTATION 

• ccaa  closeout 

• VERIE.  COMPLETION  NOTICES 
0 COUriSURATION  ACCOUMTINS 

NOTE: 

FUNCTIONS  ME  DEPENDENT  ON  REQUIREMENTS 


0 SYSTEM  I Uf  VERIFICATION 
SUPPORT 

0 PREDICTED  DATA 
ANALYSIS 

0 NAIVERS/DEVIATIONS 


Figure  4-4 


4-37 


change  request,  but  if  not,  the  configuration  management 
personnel  can  readily  determine  who  is  affected  by  noting  the 
control  documentation  affected  by  the  change  request.  For 
example,  if  an  ICD  is  affected,  the  organization  approving  that 
ICD  will  receive  copies  of  all  change  requests  affecting  that 
ICD.  The  configuration  management  personnel  must  be  familiar 
with  what  approval  level  is  affected  and  thereby  what  change 
control  board  will  have  approval  authority  for  that  change.  In 
addition  to  the  change  distribution  determined  by  configuration 
management,  a copy  of  the  change  goes  to  the  sustaining 
engineering  organization.  This  organization  accomplishes 
engineering  integration  of  the  change  request  by  determining  all 
hardware  and  software  end  items  affected  by  the  change.  If  this 
determination  identifies  organizations  responsible  for 
hardware/ software  items  affected  by  the  change  and  not  included 
on  the  distribution  list  for  the  change,  sustaining  engineering 
informs  configuration  management  to  provide  copies  to  the  new 
organizations. 

Engineering  Support 

An  engineering  change  request  is  forwarded  to  NASA  sustaining 
engineering  for  technical  assessment  of  the  change  concept,  cost 
and/or  schedule  impact.  If  the  change  is  approved,  sustaining 
engineering  will  design  the  change,  oversee  the  manufacture  of 
the  design,  test  and  verify  the  hardware  and  software,  and 
prepare  a modification  kit  for  change  incorporation  on-orbit. 
Upon  change  incorporation,  the  engineering  data  base  will  be 
revised  to  reflect  the  new  configuration. 

Change  Impacts 

All  organizations  affected  by  a change  request  must  identify  the 
impact  for  implementing  that  change.  When  all  impacts  are 
received,  the  change  request  is  ready  for  inclusion  on  the  next 
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scheduled  change  control  board  agenda.  If  the  change  is  ap- 
proved, all  affected  organizations,  as  determined  by  the  change 
integration  process,  will  be  directed  to  implement  the  change  by 
actions  assigned  and  listed  on  the  change  control  board  direc- 
tive. 

Risk  Evaluation 

For  each  engineering  change  considered,  a program  risk  evaluation 
is  accomplished  to  cover  all  program  impacts  to  costs,  schedules, 
hardware,  software,  facilities,  and  to  identify  non  SSP  affects. 
Changes  affecting  users  and/or  Internationals  must  be  ap- 
proved/concurred in  by  these  agencies  prior  to  SSP  approval . The 
NASA  change  processing  system  is  structured  to  accomplish  joint 
agency  approval  or  disapproval  for  each  change  when  required. 

Screening  Board 

A screening  authority  is  included  in  the  change  processing  flow 
to  consolidate  similar  changes  and  establish  validity  to  changes 
prior  to  further  processing.  This  authority  performs  initial 
integration  of  the  change  to  identify  the  systems  affected  by  the 
proposed  change.  Besides  affected  systems  the  screening  func- 
tions looks  at  validation  affects,  change  category  and 
effectivity,  manifest  requirements,  and  criticality.  NASA  change 
screening  authorities  will  be  established  and  must  have  access  to 
other  screening  authorities  for  changes  which  may  require  joint 
dispositions  by  other  affected  systems. 

Every  change  processing  system  has  the  capability  to  expedite 
engineering  change  approval  and  subsequent  incorporation. 

Normally  this  is  performed  as  a function  of  the  screening  board. 
Expeditious  action  depends  on  the  complexity  of  the  change,  but 
the  change  evaluation  process  can  be  reduced  to  rapid  review  and 
a meeting  with  the  appropriate  NASA  manager.  Rapid  incorporation 
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of  a change  is  dependent  upon  when  it  is  required  and  if  the 
design  and  parts  required  are  not  complex.  Incorporation  can 
occur  "real-time"  or  within  a short  space  of  time. 

Verification 


An  activity  associated  with  configuration  management  is  the 
functional  verification  of  products  (modifications).  After 
completion  of  the  development  phase,  mature  operations  begins 
with  a baseline  (engineering  design  data  base).  The  only  modifi- 
cation that  will  change  that  baseline  configuration  is  an  ap- 
proved configuration  change.  Changes  can  be  divided  into  two 
classifications  by  need:  1)  A design  improvement,  2)  A design 

fix  change,  or  failure  fix.  The  approved  changes  are  incorporat- 
ed by  modification  kits.  Modification  kits  will  include  1) 
hardware  and/or  software  changes  and  supporting  documentation  or 
2 ). documentation  changes  only,  such  as,  a change  in  performance 
criteria.  The  functional  verification  of  modifications  will 
utilize  test  fixtures  and  simulators  as  developed  during  the 
development  phase  to  validate  a Space  Station  modification.  In 
cases  of  approved  complex  engineering  changes,  sustaining  engi- 
neering may  need  to  develop  a test  fixture,  model,  or  simulator 
which  will  be  used  to  verify  the  engineering  change  during  ground 
processing.  The  requirements  for  a change  must  be  included 
during  change  evaluation  of  the  change  proposal  in  order  that  all 
change  aspects,  including  cost  and  complexity,  are  covered  prior 
to  change  approval . 

Audit /Accounting 

The  function  of  configuration  audit/accounting  assures  that  each 
design  change  (after  approval)  goes  through  satisfactory  design 
reviews,  is  verified  by  simulators,  test  beds,  models,  .... 
and/or  tests,  and  is  inspected  to  verify  the  "as-designed"  change 
equals  the  "as-built"  change  or  deviations/waivers  between  the 
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two  are  documented  and  approved  by  the  responsible  and  affected 
organizations.  After  change  incorporation,  tests  and/or  inspec- 
tions are  required  to  verify  adequate  incorporation  of  the 
change.  The  configuration  audit  cycle  is  statused  for  each 
change  at  each  milestone  completion.  The  complete  cycle  ends 
with  change  incorporation  acceptance,  and  a Incorporation  Notice 
Closure  (INC)  to  the  configuration  accounting  function  which 
closes  the  change  and  updates  the  affected  portions  of  the 
engineering  data  base  which  were  affected. 

Changes  to  Commonality  Items 

A key  process  for  configuration  management  during  mature  opera- 
tions is  change  processing  for  commonality  items.  Rigid  configu- 
ration control  procedures  will  be  established  during  the  develop- 
ment phase  for  changes  to  common  items.  These  procedures  will 
have  assured  that  all  changes  to  the  items  were  coordinated  with 
all  users  of  the  items  prior  to  change  approval.  The  procedures 
will  require  for  each  common  item  developed,  an  interface  drawing 
showing  the  common  item  interfaces,  such  as  electrical  and 
mechanical  connections,  item  mounting  arrangement, 
performance  data.  . . The  interface  drawing  will  be  approved  by 
all  common  item  users  and  baselined  for  configuration  control. 

The  baselined  interface  drawing  will  control  the  interfaces  of 
the  item  so  that  users  can  design  interfacing  hardware  at  the 
same  time  that  the  common  item  developer  composes  his  internal 
design.  The  developer  completes  the  manufacturing  and  testing  of 
the  first  unit  prior  to  considering  the  baseline  of  the  complete- 
ly designed  common  item.  After  baselining  the  complete  design, 
all  proposed  changes  to  the  item  are  coordinated  will  all  users 
of  the  item  prior  to  change  approval  and  incorporation. 
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4.4.3  Transition  Concepts 


The  mature  operations  concepts  showed  that  the  Space  Station  and 
its  dedicated  support  systems  will  have  the  execution  of  sustain- 
ing engineering  located  at  the  operations  centers.  The  major  and 
most  complex  transition  will  be  the  transfer  of  responsibilities 
for  the  flight  systems  to  the  launch  center.  For  mature  opera- 
tions, the  support  systems,  with  some  exceptions,  will  already  be 
located  and  being  sustained  at  the  operation  Centers.  This 
section  of  the  report  will  concentrate  on  the  transfer  of  engi- 
neering expertise  and  capabilities  for  complex  flight  systems, 
keeping  in  mind  that  these  concepts  can  also  be  applied  to  the 
support  systems. 

Transition  Plans 

For  mature  operations  to  occur  and  be  successful , transition 
plans  and  requirements  must  be  established  early  in  the  develop- 
ment phase.  The  guidelines,  criteria,  and  requirements  for 
mature  operations  are  established  by  Space  Station  operations. 
Each  of  the  Work  Package  Centers  and  the  operations  centers  must 
develop  the  implementation  plans  in  concert  with  each  other. 

These  plans  must  cover  the  roles  and  responsibilities  for  civil 
service  organizations  and  their  supporting  contractors  and  define 
tools,  equipment,  facilities,  software,  data  bases,  documenta- 
tion. . . which  are  to  be  transferred  both  physically  and/or 
in-place  to  the  operations  organizations  and  centers.  Other 
criteria  in  these  plans  will  include  management  plans,  evolu- 
tion/growth relationships,  safety.  Logistics,  Information  Systems 
. . . and  the  interrelationships  associated  with  mature  opera- 
tions . 
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Sources  of  Engineering  Expertise 


Various  sources  of  engineering  expertise,  civil  service  and 
contractor  personnel,  will  evolve  during  the  development  phase. 
Pending  definitions  of  evolution/growth  programs,  a significant 
number  of  engineering  personnel  with  space  station  expertise  will 
no  longer  be  required  after  the  development  phase  and  completion 
of  contracts.  Rather  than  losing  this  expertise  to  other  pro- 
grams, the  transfer  of  experienced  personnel  into  operations 
organizations  is  an  important  aspect  to  mature  operations. 

During  the  development  phase  the  Systems  Engineering  and  Integra- 
tion (SE&I)  organization  with  its  contractor  will  have  distribut- 
ed elements  at  the  Work  Package  locations  which  includes  the 
launch  center  and  flight  operations  centers.  The  SE&I  function 
will  develop  considerable  engineering  expertise  and  knowledge 
which  will  provide  a substantial  engineering  base  (civil  service 
and  contractor)  for  mature  operations.  This  base  contains  mostly 
integrated  engineering  requirements  expertise. 

The  Work  Package  Design  centers  and  their  contractors  will  have 
evolved  an  engineering  base  of  Space  Station  expertise  which, 
again,  may  be  lost  to  other  programs  if  not  involved  in  Space 
Station  evolution.  The  expertise  base  has  strong  design  and 
engineering  analysis  capabilities. 

Significant  knowledge  and  expertise  will  be  gained  at  the  opera- 
tions centers  during  the  prelaunch  and  on-orbit  assembly  and 
checkout  as  part  of  the  development  phase.  Substantial  engineer- 
ing expertise  is  gained  in  the  prelaunch  installation,  test,  and 
checkout  of  modifications  implemented  and  user  instrument  inte- 
gration after  delivery  of  flight  hardware/ software  to  the  launch 
center.  This  expertise  will  be  retained  into  mature  operations. 
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Types  of  Sustaining  Engineering 


The  engineering  required  during  the  later  stages  of  the  develop- 
ment phase  can  generally  be  categorized  into  the  following  three 
types : 


Type  Location 

I Launch  Center 

II  Development  Centers 


Description 

Implementation  of 
modifications  and 
payload  integration 

Design  and  Analysis 


III  Development  Centers  Payload  Integration  Analysis 

Type  I -Modification  Implementation  and  Payload  Integration*  As 
the  final  stage  in  the  modification  process  and  payload  integra- 
tion prior  to  launch,  modification  kits  and  payloads  are  deliv- 
ered to  the  launch  center  to  be  installed,  verified,  and  checked 
out.  The  launch  center  by  definition  is  a centralized  location 
where  all  hardware  is  processed  prior  to  launch.  The  day-to-day 
relationship  with  space  station  hardware  and  user  equipment  will 
require  field  engineering  changes  at  the  launch  center.  These 
changes  will  be  identified  and  defined  by  the  launch  center  and 
certified  by  the  development  center. 


Type  II  - Design  and  Analysis.  The  development  centers  are 
responsible  for  the  design  and  related  engineering  analysis  of 
modifications  to  the  Space  Station.  Depending  on  the  complexity 
of  the  modifications,  more  than  one  development  center  may  be 
involved  in  the  design/analysis.  The  analysis  of  the  design  is 
required  to  ascertain  compatibility  with  the  Space  Station. 


Type  III  - Payload  Integration  Analysis  - Prior  to  payloads  being 
certified  to  fly  on  the  space  station,  an  engineering  analysis  is 
required  to  certify  that  the  payload  is  compatible  with  the  space 
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station  for  the  up load /down load  and  on-orbit  operations.  The 
analysis  performed  is  nearly  identical  to  that  required  for  Type 
II. 


Transition  Stages 

In  the  transition  from  the  development  phase  to  mature  opera- 
tions, four  stages  or  milestones  are  identifiable.  Each  stage  is 
a gradual  buildup  of  engineering  capability  in  preparation  for 
the  concept  of  centralizing  the  sustaining  engineering  for  flight 
systems  including  the  integration  of  payloads  during  mature 
operations.  Figure  4-5  shows  these  stages  relative  to  the  Space 
Station  program. 


Stage  I - Development  and  Assembly  Phase.  The  transition  func- 
tions for  stage  I are  as  follows: 

o Development  and  definition  of  transition  plans  and 
requirements 

o Participation  in  requirement  reviews 

o Initial  representatives  in-residence  (initially  by  civil 
service  and  later  by  contractor) 

o Participation  in  design  reviews 

o Establish  ROM  schedules  for  turnover  in  late  development 
and  assembly  phase 

o Finalize  detailed  plans  by  each  operation  center  approx- 
imately four  years  prior  to  mature  operations 

o Operations  contract  established  at  mid -development  phase 

o Engineering  Types  I,  II,  and  III  performed  by  developers 
except  after  delivery  Type  I is  performed  at  launch 
center. 
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TRANSITION  CONCEPT 


Stage  II  - 3 Yeara  Prior  to  Mature  Operations.  This  stage  may 
overlap  into  Stage  I or  III  depending  on  the  turnover  date.  The 
transition  functions  are  as  follows: 

o Civil  service  and  operation  contractor  core  of 

engineers  established  and  represented  for  each  system 
and  subsystem 

o Core  has  defined  roles  and  responsibilities  in  support 
to  developers  such  as  system  and  user  analysis 

o Engineering  Type  I performed  at  launch  center  and  Types 
II  and  III  performed  by  developers 

Stage  III  - Initial  Operations/Post  Assembly  Phase.  Initial 
operations  is  a variable  time  span  depending  on  maturity  of 
design  and  status  of  operational  expertise.  The  transition 
functions  are  as  follow: 

o Build-up  towards  full  staff  and  organization 

o Engineering  Type  I performed  at  launch  center  and  Types 
II  and  III  performed  by  developers 

o Minor  changes/modifications  performed  by  operations  with 
certification  approvals  by  developers 

o Turnover  of  less  complex  systems  consisting  primarily  of 
support  systems  with  support  from  developers 

o Stages  II  and  III  are  totally  overlapped  for  complex 
systems  and  can  be  defined  as  a singular  stage  whereby 
initial  operations  may  be  longer  than  3 years 

Stage  IV  - Mature  Operations.  Mature  operations  begins  when 
operational  expertise  is  in-place  and  design  has  matured.  The 
transition  functions  are  as  follows: 

o Full  staff  and  organization  in-place  with  civil 

service-to-contractor  engineer  ratio  of  l-to-12  (mini- 
mum) 

o Final  turnover  of  responsibilities 

o Support  from  developer  (where  still  active  in  evolu- 
tion/growth) on  an  "on-call"  basis 
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o Support  by  operations  to  evolution /growth  activities 

o Types  I,  II,  and  III  of  engineering  performed  at  the 
launch  center  (Flight  Systems) 

Engineering  Expertise  Development 

The  transition  phase  overlaps  the  development  phase  and  initial 
operations.  The  length  of  the  transition  phase  will  vary  depend- 
ing on  the  complexity  of  the  systems  and  turnover  requirements. 

It  is  recommended  that  the  transition  phase  with  an  engineering 
core  begin  3 years  prior  to  mature  operations.  This  will  provide 
3 years  for  the  operational  organizations  to  perform  detailed 
planning  and  establish  detailed  procedures  for  all  operational 
phase  activities  prior  to  its  start.  The  3 year  transition  phase 
is  needed  for  a new  contractor  to  prepare  for  and  gain  expertise 
from  the  individual  Work  Package  (WP)  contractors  in  order  to  be 
ready  to  perform  sustaining  engineering  at  the  start  of  the 
mature  operational  phase. 

Once  the  sustaining  engineering  organization  is  established 
and/or  contracted  the  entire  transition  phase  will  be  oriented 
towards  preparing  for  mature  operations.  This  preparation  will 
be  accomplished  by  interfacing  with  the  development  Work  Package 
contractors  and  the  Program  Support  contractor  to  develop  a Space 
Station  design  expertise. 

The  sustaining  engineering  organization  will  develop  Space 
Station  design  expertise  by  a combination  of  the  following 
activities : 

1.  On-the-job  training  in  working  closely  with  Work 
Package  contractor  counterparts. 

2.  Studying  and  reviewing  Space  Station  program  control 
documentation  such  as  specifications,  ICD's,  and 
engineering  drawings. 
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3.  Training  classes  on  the  Space  Station  design  taught  by 
the  Work  Package  contractors. 

4.  Studying  and  reviewing  engineering  design  analyses, 
test  results,  failure  mode  & effects  analyses,  and 
design  knowledge  capture  data  as  a support  role  to  the 
Work  Package  development  activities. 

5.  Participating  in  design  reviews,  acceptance  reviews, 
mission  simulations,  and  other  activities  occurring 
during  the  design  and  development  phase. 

A key  function  for  the  transition  phase  is  the  maintenance  of  the 
Space  Station  engineering  data  base.  Although  this  maintenance 
will  be  the  responsibility  of  the  Work  Package  contractors  during 
the  transition  phase,  the  operational  sustaining  engineering 
organization  will  review  this  data  base,  assess  changes  .and 
become  capable  of  maintaining  the  engineering  baseline  when 
mature  operations  begin.  The  transitional  phase  will  focus  on 
transferring  the  maintenance  responsibility  of  the  engineering 
data  base,  engineering  drawing  files,  and  historical  design 
analyses  which  documented  design  alternatives  considered  by  the 
Work  Package  contractors  and  the  rationale  for  selecting  the  most 
optimum  alternative.  By  studying  these  analyses,  an  organization 
other  than  the  Work  Package  design  and  development  contractor 
will  be  able  to  achieve  design  authority  and  be  responsible  for 
Sustaining  Engineering  of  Space  Station  hardware  and  software 
during  mature  operations. 

Turnover  Reviews 

NASA  will  determine  the  progress  made  by  the  sustaining  engineer- 
ing organization  in  gaining  the  design  knowledge  of  the  Space 
Station.  This  will  primarily  be  accomplished  by  periodic  status 
reviews  throughout  the  transition  phase  and  culminate  in  a 
turnover  review  for  each  Space  Station  Program  hardware/ software 
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end  item*  The  Space  Station  development  phase  is  managed  by- 
dividing  all  Space  Station  hardware  and  software  into  specific 
identifiable  end  items.  To  determine  the  state  of  readiness  of 
each  end  item  for  mature  operations,  NASA  shall  conduct  a turn- 
over review  for  each  item.  At  this  review  the  responsible  Work 
Package  contractor  will  present  the  design  and  hardware  status  of 
each  end  item  and  its  readiness  for  mature  operations.  The 
sustaining  engineering  organization  will  present  the  status  of 
his  expertise  on  the  item  and  the  adequacy  of  the  engineering 
data  base  of  the  item  to  be  transferred.  Open  items  and  remain- 
ing actions  are  presented  at  the  review  and  agreement  is  made  as 
to  responsibility  of  closure.  On  an  end  item  basis  there  will  be 
many  turnover  reviews;  however,  one  review  may  cover  many  end 
items,  especially  in  the  case  of  non-complex  GSE  or  software  end 
items.  For  items  already  existing  in  orbit,  the  review  must 
identify  the  complete  configuration  of  the  item,  including 
approved  waivers  -which  permitted  design  departures.  In  rare 
cases,  action  may  be  taken  to  to  inspect  the  item  on-orbit  and 
provide  a description  of  the  area  in  question  to  the  turnover 
review  authority.  It  is  expected  that  the  non-complex  designed 
items  will  have  a turnover  review  early  in  the  transition  phase 
while  the  more  complex  items  will  have  their  reviews  later.  The 
number  of  end  items  will  require  the  turnover  reviews  to  be 
conducted  incrementally. 

Upon  completion  of  all  of  the  turnover  reviews  and  upon  closeout 
of  all  actions  assigned  at  these  reviews,  the  Space  Station 
hardware  and  software  will  be  ready  for  mature  operations.  The 
turnover  reviews  will  establish  a mutually  agreeable  status  of 
the  hardware  and  software  end  items  at  mature  operations  and  the 
capability  of  the  operations  sustaining  engineering  organization 
to  receive  the  engineering  design  authority  for  the  Space  Sta- 
tion. The  reviews  may  also  cover  other  aspects  of  mature  opera- 
tions readiness,  such  as,  spares  status,  logistics  status,  . . ., 
as  determined  by  NASA. 
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Configuration  Management  Transition 


The  configuration  management  (CM)  activity  is  interrelated 
closely  to  sustaining  engineering  activities  during  mature 
operations.  A transition  phase  is  needed  at  the  end  of  the 
development  phase  for  a configuration  management  organization  to 
assume  responsibility  for  the  configuration  management  functions. 
The  turnover  of  this  responsibility  shall  occur  in  a manner 
similar  to  and  in  conjunction  with  the  turnover  of  the  sustaining 
engineering  responsibility.  At  the  completion  of  reviews  for  all 
end  items,  the  total  CM  responsibility  will  be  transferred  to  the 
new  configuration  management  organization.  In  a similar  manner 
as  sustaining  engineering,  configuration  management  will  submit 
plans  and  procedures  to  NASA  for  approval . Upon  NASA  approval , 
the  configuration  management  organization  will  be  ready  to  start 
mature  operations.  Another  area  of  responsibility  which  the 
configuration  management  organization  must  assume  is  the  genera- 
tion of  various  status  reports,  which  include  change  processing 
status,  document  change  status,  change  approval,  mod  kit  status, 
and  change  incorporation  status,  ....  All  of  these  status 
reporting  responsibilities  are  transferred  from  the  Work  Package 
contractors  to  the  new  configuration  management  organization  when 
agreed  to  by  NASA  and  the  two  elements  involved.  This  transfer 
may  be  accomplished  on  a report-by-report  basis  or  a one  time 
basis,  whichever  is  mutually  agreeable.  The  requirement  being 
that  the  new  configuration  management  organization  will  have 
received  all  of  the  development  phase  configuration  management 
responsibilities  for  implementation  at  the  beginning  of  mature 
operations . 
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4.4.4  Special  Topics 


4. 4. 4.1  Tools  and  Facilities 

To  facilitate  the  sustaining  engineering  functions,  design/devel- 
oproent  tools  used  as  simulators,  test  beds,  analysis  models.  . . 
will  be  provided  or  made  accessible  to  the  operational  sustaining 
engineering  organizations.  During  the  transition  phase  these 
items  and  agreements  for  access  will  be  defined.  The  transition 
plans  and  agreements  must  include  those  tools  and  facilities 
which  require  physical  relocation.  In  cases  where  the  sustaining 
engineering  organization  is  the  primary  user,  the  tools  and 
facilities  will  be  located  at  that  site.  These  tools  will  be 
required  by  sustaining  engineering  for  modification  verification, 
analysis,  training,  anomaly  investigations,  and  information 
storage  and  retrieval . 

v 

For  sustaining  engineering  to  adequately  and  properly  perform  its 
function,  certain  tools  and  physical  space  is  required.  These 
requirements  will  be  identified  and  briefly  described. 

Tools  and  facilities  required  can  be  categorized  into  four  areas: 
analytical,  functional,  informational  and  production. 

Analytical . The  prime  analytical  tools  required  are  computer 
models.  These  aire  required  to  support  engineering  analysis  of 
performance  including  up load /down load  characteristics.  The 
computer  models  will  be  used  to  analytically  determine  mass 
properties,  thermal,  dynamics,  stress  and  other  parameters.  They 
are  also  needed  to  perform  software  analysis  related  to  changes 
or  upgrades  in  the  SSE. 

Functional . Functional  tools  are  needed  to  verify  planned 
modifications  prior  to  implementation  and  for  training  installa- 
tion crews  and/or  developing  step-by-step  installation  and 
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checkout  procedures.  These  tools  include  test  beds,  test  fix- 
tures, trainers,  and  simulators.  Facility  space  is  needed  to 
accommodate  these  tools  and  also  to  provide  an  area  for  hardware 
and  software  integration  [Multisystems  Integration  Facility] 
(MSIF).  Modification  and  performance/design  verification  includ- 
ing training  and  failure  simulations  will  be  conducted  in  this 
area.  This  facility  is  shared  with  operations.  Software  data 
may  be  electronically  transmitted  for  verification  in  this 
facility. 

i 

Information  Systems.  Information  systems  and  performance  moni- 
toring facilities  are  needed  to  support  a wide  variety  of  sus- 
taining engineering  functions.  For  example,  access  to  engineer- 
ing documentation  and  configuration/failure  status  is  a function 
that  requires  TMIS  support.  Performance  monitoring  facilities 
are  needed  to  monitor  real-time  data  and  accumulated  or  compiled 
data.  These  are  provided  as  either  a remote,  or  local  capability 
and  would  be  similar  to  todays  HOSC  or  MER  type  functions. 

Production.  Software  production  facilities  and  small  scale 
manufacturing  facilities  are  required  to  produce  software  changes 
and  hardware  modification  kits  and  mock-ups  . For  producing 
design  drawings  and  related  documents,  CAO/CAE  systems  compatible 
with  TMIS  is  required.  Also,  office  space  for  sustaining  engi- 
neering personnel  will  be  needed. 

4. 4. 4. 2 Interface  Control  Documents  (ICD's) 

I CD's  are  used  to  document  the  interface  design  between  two  or 
more  elements  furnished  by  two  or  more  design  agencies.  Both 
agencies  approve  the  design  and  sign  the  final  ICD.  At  this 
point,  the  design  is  baselined. 

Proposed  changes  to  the  ICD  design  are  submitted  by  preliminary 
interface  revision  notices  (IRN's)  to  the  appropriate  change 


4-53 


boards.  The  preliminary  IRN's  should  be  coordinated  with  both 
interfacing  agencies  to  assure  that  the  IRN  design  is  technically 
feasible.  The  IRN  design  should  also  be  coordinated  with  NASA 
and  other  affected  agencies. 

After  the  proposed  change  is  completely  evaluated,  the  chairman 
of  the  change  board  approves  or  disapproves  the  change.  If 
approved,  the  change  board  directive  documents  the  approval.  The 
directive  is  not  released  until  an  approval  directive  is  received 
from  the  interfacing  change  board.  The  second  directive  is 
referenced  on  the  first  and  the  CCBD  is  released.  The  CCBO 
directs  the  design  agency  to  change  his  hardware/ software  design 
to  comply  with  the  IRN. 

The  interfacing  CCBO  also  directs  the  interfacing  agency  to 
comply  with  the  IRN.  Upon  approval  of  the  IRN's  against  an  ICD, 
the  ICD  is  updated  to  a new  revision  which  incorporates  all  of 
the  approved  IRN's. 

ICD 's  should  be  baselined  as  soon  as  possible  after  the  Prelimi- 
nary Design  Review  (PDR)  for  the  hardware.  The  preliminary 
design  should  include  preliminary  interface  design  which  should 
be  finalized  after  all  interfacing  elements  have  approved  it. 

When  approved,  the  ICD  drafting  can  begin.  Upon  completion  of 
ICD  preparation,  the  ICD  can  be  coordinated  and  approved  by  all 
affected  agencies.  It  is  then  baselined  and  placed  under  config- 
uration change  control.  All  subsequent  design  changes  which 
affect  the  ICD  must  be  proposed  by  preliminary  IRN  and  approved 
prior  to  release  of  design  changes. 

All  physical  and  functional  interfaces  are  documented  in  ICD's. 
Physical  interfaces  are  mechanical,  electrical,  environmental, 
dynamic  and  envelopes.  Functional  interfaces  include  procedural 
and  operational,  i.e.  torque  requirements  for  tightening  fasten- 
ers on  a cover  which  must  be  accomplished  in  a specific  sequence. 
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Electrical  pin  functions  would  be  a functional  interface. 
Operational  constraints  will  also  be  included  in  these  ICO's. 

ICD's  are  required  between  interfacing  design  agencies,  i.e.,  two 
contractors  or  NASA  and  ESA.  If  the  same  agency  is  responsible 
for  both  hardware  items  which  have  a physical  interface,  then 
engineering  drawings  are  sufficient  for  controlling  the  interface 
design. 

In  some  cases,  the  Space  Station  will  provide  standard  or 
one-sided  ICD's,  specifically  where  interfaced  systems  vary  or 
change  often  and  are  noncritical  to  safety.  The  utilization  of 
standard  ICD's  is  cost  effective  by  reducing  maintenance  of 
ICD's;  performance  can  be  maintained  with  effective  planning  of 
standards  and  criteria.  This  concept  is  particularly  applicable 
to  user  racks,  logistics  carriers,  and  stowage  containers.  An 
example  of  this  ICD  would  be  the  documenting  of  standard  inter- 
faces for  the  users.  These  ICD's  would  show  the  design  of  the 
Space  Station  which  would  accommodate  user  experiment  connec- 
tions, such  as  electrical  connections,  mechanical  attach  points, 
fluid  connections,  . . . Only  the  Space  Station  side  of  the 
interface  would  be  shown.  As  long  as  a user  meets  the  require- 
ments of  this  one-sided  ICD,  the  Space  Station  design  would  not 
be  changed;  the  user  still  would  be  required  to  provide  design 
and  performance  data  to  the  interface.  If  one  user  required  a 
change  to  this  standard  interface,  he  would  coordinate  his 
requirement  with  the  sustaining  engineering  element  and  if 
feasible,  a new  interface  would  be  designed  to  accommodate  this 
user.  A new  or  unique  ICD  would  be  initiated  showing  this  design 
and  would  be  approved  by  both  the  Space  Station  Program  and  the 
affected  user.  The  new  ICD  would  then  be  subject  to  configura- 
tion control.  This  ICD  would  be  effective  for  the  Space  Sta- 
tion/user from  joint  approval  through  the  end  of  the  experiment 
mission.  At  that  time  the  Space  Station  hardware  must  be  changed 
and  returned  to  match  the  original  one-sided  ICD  interface. 
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Since  the  user  to  Sp^ce  Station  interface  must  be  returned  to  the 
standard  interface,  care  must  be  maintained  in  designing  peculiar 
user  interfaces  so  this  can  be  readily  accomplished.  When  using 
standard  ICD's,  the  Space  Station  Program  would  still  be  required 
to  assess  and  analyze  the  compatibility  of  the  user  design  and 
performance  with  the  Space  Station. 


4. 4. 4. 3 Maintaining  Expertise 


Sustaining  engineering  is  an  ongoing  function  and  an  assigned 
task  for  the  Space  Station  Program.  Sustaining  the  operations 
requires  day-to-day  performance  analysis,  solving  potential 
problems  prior  to  outright  failures,  and  ensuring  contingency 
planning  is  kept  up-to-date.  Trainers  and  simulators  are  excel- 
lent tools  for  developing  contingency  plans  and  for  the  training 
of  operators,  flight  crews,  and  engineers.  As  a method  for 
maintaining  engineering  expertise,  sustaining  engineering  shall 
have  the  responsibility  of  developing  induced  failures  in  train- 
ers and  simulators  in  the  training  of  personnel. 


Sustaining  engineering  will  also  be  involved  in  the  evolu- 
tion/growth design  programs  in  a support  role.  An  operations 
perspective  is  provided  in  the  review  of  the  evolution/growth 
designs.  Sustaining  engineering  will  also  review  and/or  perform 
the  technical  risk  factor  assessments  and  analyze  the  impacts  on 
the  existing  apace  station  systems.  Besides  a means  of  maintain- 
ing expertise,  involvement  in  evolution/growth  also  provides  the 
mechanism  for  developing  the  expertise  necessary  to  perform  the 
sustaining  functions  when  the  evolution/growth  designs  become 
operational . 

Advanced  technology  programs  also  provides  an  opportunity  to 
maintain  and  advance  expertise  for  sustaining  engineering. 
Selected  programs  shall  be  allowed  in  the  sustaining  engineering 
organization  for  special  studies  and  assessments  for  potential 
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adaptability  to  the  Space  Station.  Careful  selection  is  required 
to  ensure  these  programs  remain  as  a secondary  function  to  the 
sustaining  engineering's  primary  role  of  sustaining  the  Space 
Station . 


4. 4. 4. 4 Rack  Staging 

Rack  staging  is  the  process  of  configuring  flight  racks  with 
Space  Station  hardware  and  components  to  accommodate  user  instru- 
ments. In  the  Spacelab  Program  the  hardware  consisted  of  passive 
and  active  components.  Passive  components  included  standard 
storage  containers,  hand  rails,  support  struts,  attach  points, 
and  cooling  cover  plates.  Active  components  included  remote 
acquisition  units  (multiplexers),  intercom  units,  TV  systems, 
heat  exchangers,  fire  suppression  systems,  and  cooling  ducts. 

For  each  mission,  configuration  drawings  and  physical  reconfigu- 
ration of  the  racks  were  required  at  substantial  costs  to  the 
design  agency  and  the  launch  center. 

Considering  that  the  Space  Station  Program  is  planning  on  at 
least  six  sets  of  racks  (10  per  set),  substantial  cost  savings  in 
sustaining  engineering  and  ground  processing  can  be  realized  by 
standardizing  all  racks  and  reducing  or  eliminating  the  active 
components  in  the  racks.  Active  components  should  be  designed  to 
be  external  to  the  racks  (such  as  placed  in  permanently  located 
subsystem  racks).  Standard  interfaces  should  be  defined  for  user 
accommodation.  The  foregoing  is  based  on  the  shipment  of  racks 
off-site  to  other  locations  whereby  with  active  components 
installed,  additional  maintenance  and  sustaining  costs  can  be 
expected  by  the  Space  Station  Program. 

In  summary,  the  design  of  the  racks  should  be  standardized  for 
user  accommodation  with  minimal  Space  Station  active  components 
required  internally,  particularly  if  the  racks  are  shipped  to 
other  locations. 
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4. 4. 4. 5 Estimating  Techniques 


There  are  many  factors  that  affect  the  manpower  required  to 
perform  sustaining  engineering.  For  example,  the  number  of 
approved  changes  in  evolving  requirements,  number  of  product 
performance  improvements,  and  the  operational  enhancement  rede- 
signs that  required  for  more  cost  effective  operations  all  impact 
sustaining  engineering  manpower.  These  type  of  factors  are  not 
accurately  predictable.  However,  we  can  use  past  program  experi- 
ences to  develop  cost  estimating  relationships  that  will  give 
some  guidance  in  what  to  expect  for  Space  Station  sustaining 
engineering  costs. 

The  basic  approach  is  to  determine  sustaining  engineering  manpow- 
er on  an  annual  basis  as  a percentage  of  total  development 
engineering  manpower  for  a given  system  or  program  and  apply  that 
percentage  as  a predictor  for  future  programs.  In  reviewing 
Apollo  statistics,  it  was  determined  that  for  Kennedy  Space 
Center  ground  systems,  the  annual  sustaining  engineering  manpower 
was  2.6%  of  the  total  engineering  development  manpower  for  those 
same  systems  (See  Figure  4-6).  The  sustaining  level  for  ground 
systems  began  after  the  seventh  Apollo  launch.  For  Shuttle 
Kennedy  Space  Center  ground  systems  the  factor  is  2.7%  (See 
Figure  4-7),  with  sustaining  beginning  after  the  14th  Shuttle 
launch.  This  excludes  LPS.  For  systems  with  heavy  software 
applications,  the  estimating  factor  increases  substantially. 

Based  on  CITE/OFS  statistics,  the  sustaining  engineering  annual 
percentage  increases  to  6.6%.  The  equipment  and  material  cost 
required  to  implement  the  sustaining  modification  is  equivalent 
to  an  additional  50%  of  this  sustaining  engineering  manpower 
cost. 
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ENGINEERING  MANPOWER 


With  these  factors  from  past  programs,  the  Kennedy  Space  Center 
sustaining  engineering  manpower  and  materials  cost  for  Space 
Station  mature  operations  can  be  estimated  based  on  the  engineer- 
ing manpower  budgeted  for  Space  Station  development.  Taking  the 
2.7%  and  6.6%  estimating  factors  as  predictors  for  the  annual 
sustaining  engineering  manpower  and  applying  it  to  the  most 
recent  cost  commitment  development  manpower  estimates  results  in 
a sustaining  engineering  manpower  level  of  about  100  man-years 
per  year.  This  means  that  based  on  past  Apollo  and  Shuttle 
sustaining  engineering  manpower  data  it  should  require  about  100 
direct  equivalents  per  year  for  the  sustaining  engineering  of 
Kennedy  Space  Center  developed  systems  for  Space  Station.  Since 
Apollo  and  Shuttle  were  much  larger  development  programs  for 
Kennedy  Space  Center  than  Space  Station  ( roughly  five  times  the 
man-years),  there  may  be  some  economies  of  scale  not  realized  for 
Space  Station.  In  that  case  the  100  man-years  would  be  low. 
However,  since  there  is  already  a base  of  engineering  support 
providing  sustaining  engineering  for  the  same  types  of  systems 
(payload  and  shuttle)  as  for  Space  Station,  the  increase  required 
for  sustaining  Space  Station  systems  may  be  less  and  tend  to 
offset  the  economies  of  scale  handicap. 

This  analysis  is  only  for  Kennedy  Space  Center  systems,  but  the 
approach  could  be  applied  to  other  NASA  systems.  However,  it  may 
be  difficult  to  determine  estimating  relationships  for  flight 
systems  since  historically  mature  operations  have  not  been 
achieved.  And  even  though  Kennedy  Space  Center  estimating 
relationships  may  be  applied  to  other  NASA  support  systems,  it 
probably  would  not  be  appropriate  for  higher  criticality  flight 
systems.  Further  study  and  analysis  is  needed  to  better  estimate 
sustaining  engineering  manpower  and  cost  projection  for  Space 
Station  mature  operations. 


4-61 


4.5  OPTION  EVALUATION 


Option  areas  can  be  categorized  into  three  ( 3 ) major  areas  with 
suboptions  defined  in  each  of  the  major  categories: 

1.  Centralization  and  Autonomy 

Space  Station  Flight  Systems 

- Internationals 

- Users 

- Support  Systems 

2.  Risk  Acceptance  and  Planning 

- Prelaunch  verification 

- Contingency  planning 

3.  Design  Factors 

- Automation 

- Evolution 

- Supportability  and  Maintenance 

- Commonality 

4.5.1  Centralization  and  Autonomy 

A centralized  management  operations  system  for  configuration 
management  control  of  the  Space  Station  flight  systems  and  its 
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interfaces  with  other  systems  is  essential  and  thereby  a basic 
premise  in  analyzing  various  options. 

Minimum  controls  and  requirements  by  a centralized  configuration 
control  of  interfaces  with  the  Space  Station  flight  systems 
include: 

1.  Direct  interface  accommodation  involving  physical  and 
functional  areas. 

2.  Factors  affecting  the  safety  of  the  Space  Station  and 
crew. 

3.  Environmental  controls  which  include  contamination,  RF 
radiation,  thermal,  vibration,  acoustical,  and  others. 

4.  Commonality  of  hardware  and  software. 

5.  Specified  resource  data  access  to  other  interfacing 
organizations  including  design  and  performance  data. 

The  option  evaluation  of  centralized,  consolidated,  and  distribu- 
tive systems  for  sustaining  engineering  functions  and  configura- 
tion management  is  heavily  weighted  by  commonality  of  hardware 
and  software.  The  effectiveness  of  costs,  configuration  manage- 
ment systems,  and  sustaining  engineering,  are  considerably 
improved  in  areas  of  high  commonality  by  centralization  and 
consolidation.  Duplication  of  engineering  efforts  in  distributed 
areas  and  enclaves  drives  cost  effectiveness  to  lower  levels. 
Configuration  management  controls  from  centralized  and  consoli- 
dated management  systems  provides  for  effective  management 
controls  of  common  hardware  and  software.  There  is  the  tendency 
where  uniqueness  exists  with  minimal  interfaces  that  greater 
autonomy  is  allowed  with  minimum  controls  from  centralized 
systems . 
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Space  Station  Flight  Systems  Options.  Option  1.  Space  Station 
Work  Package  centers  perform  sustaining  engineering  and  Space 
Station  operations  management  controls  interfaces  between  ele- 
ments and  distributive  systems. 

Option  2.  Space  Station  evolution /growth  contractor  performs 
sustaining  engineering  from  a centralized  system  under  the 
management  of  Space  Station  operations. 

Option  3.  Space  Station  operations  perform  sustaining  eng4-~ 
neering  with  contractor  directed  support  from  evolution/growth 
Contractor.  Configuration  control  management  is  performed  by 
Space  Station  operations. 

Option  1)  Work  Package  Center  Concept  - This  option  is  more 
typical  and  historical  in  the  method  of  performing  sustaining 
engineering  within  NASA-  Space  programs.  The  major  programs  were 
short-lived  in  comparison  to  the  life  span  of  space  station  in 
its  operational  phase  and  did  not  progress  to  the  mature  opera- 
tions phases  as  planned  for  the  Space  Station. 

The  effectiveness  of  management  is  considered  low  in  that  this 
option  relies  on  developers  and  development  centers  to  perform 
sustaining  engineering  more  from  the  perspective  of  development 
motives  rather  than  an  operations  viewpoint.  A heavy  reliance  on 
the  expertise  of  the  developer  in  defining  the  rationale  and 
accommodations  for  changes  and  enhancements  to  Space  Station 
operations  management  can  and  does  result  in  many  changes  not 
essential  or  mandatory  to  operations.  The  efficiency  of  working 
across  interfaces  involves  the  integration  of  many  management 
systems  of  Work  Package  design  centers  and  developers.  The 
development  of  evolutionary,  growth  and  new  programs  lessens  the 
motivation  in  sustaining  the  operations  of  the  space  station. 
Transition  costs  and  planning  are  minimal  due  to  initial  techni- 
cal expertise  and  design  knowledge  depth. 
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Option  2)  Combined  Evolution/Growth  and  Sustaining  Engineering  - 
A single  contractor  managed  by  operations  to  perform  both  sus- 
taining engineering  and  evolution/ growth  development  requires 
in-residence  time  at  the  Work  Package  contractor's  locations 
during  the  development  phase.  This  is  necessary  to  develop 
design  skills  and  knowledge  to  perform  sustaining  engineering 
during  mature  operations.  It  also  affords  the  opportunity  for 
input  to  design  from  the  operations  perspective  while 
in-residence  training  takes  place. 

The  phase-in  from  Work  Package  contractor  to  OPS  contractor  will 
take  place  gradually,  maturing  at  the  beginning  of  the  mature 
operations  phase.  The  operating  contractor  should  be  on  contract 
during  the  development  phase  about  three  years  prior  to  final 
turnover  of  responsibility.  This  is  necessary  to  improve  the 
initial  depth  of  technical  expertise  and  design  knowledge. 

Osing  the  evolution /growth  contractor  to  perform  sustaining 
engineering  on  a centralized  basis  allows  greater  flexibility  in 
shifting  resources  and  greater  consolidation  of  duplicate  engi- 
neering capability.  Interface  issues  are  more  easily  resolved 
and  the  evolution/growth  contractor  is  fully  involved  and  aware 
of  sustaining  changes  affecting  growth  development.  Placing 
management  of  their  contract  under  operations  will  help  prevent 
the  development  perspective  from  resulting  in  numerous  sustaining 
engineering  changes  not  essential  or  mandatory  to  operations . 
However,  it  is  not  as  effective  as  a separate  contractor  respon- 
sible only  for  sustaining  engineering  with  a few  evolution/growth 
representatives  contract  directed  to  support  the  sustaining 
effort  ( See  Option  3 ) . 

Another  advantage  of  this  option  is  tfye  readily  available  re- 
sources to  accommodate  large  sustaining  design  tasks.  This  is  a 
benefit  derived  from  combining  growth  development  and  sustaining 
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engineering  resources.  However,  there  could  be  some  dilution  of 
interest  in  sustaining  engineering  due  to  evolution/growth 
projects. 

Transition  costs  and  planning  in  going  from  the  design  and  . 
development  phase  to  mature  operations  may  be  significant  since 
considerable  development  expertise  will  have  to  be  transferred  to 
the  evolution/growth  contractor  prior  to  mature  operations. 
Transition  may  be  made  more  difficult  if  growth  does  not  start 
until  after  mature  operations  begins.  However,  if  the  evolu- 
tion/growth contractor  is  in  place  several  years  before  mature 
operations  begin,  it  would  facilitate  transition  for  the  purpose 
of  assuming  sustaining  engineering  responsibility  from  the  prime 
developers.  It  is  assumed  that  the  growth  contractor  will  be  one 
or  more  (but  not  all)  of  the  prime  development  contractors. 

i 

A centralized  system  for  the  users  to  work  with  on  day-to-day 
issues  will  enhance  the  operations  perspective  and  facilitate  the 
resolutions  of  interface  issues  at  lower  management  levels. 

Option  3)  Centralized  Sustaining  Engineering  with  Evolu- 
tion/Growth linkage  - A single  operations  contractor  for  sustain- 
ing engineering  with  a small  team  of  evolution/growth  contractors 
representatives  assigned  for  support  and  liaison  is  similar  to 
Option  2 except  that  evolution/growth  development  responsibility 
is  a separate  contract.  If  major  design  is  required,  the  OPS 
contractor  can  utilize  the  evolution /growth  contractor  on  an 
on-call  basis.  The  growth  development  contractor  is  assumed  to 
be  a Work  Package  development  contractor < s ) . 

This  option  requires  the  same  transition  plan  as  described  for 
Option  3.  It  will  entail  significant  up-front  transition  costs 
and  planning  but  should  prove  cost  effective  over  the  long  term 
because  of  reduced  dependance  on  high  cost  development  support. 
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A level  of  expertise  and  capability  is  retained  within  the  Space 
Station  operations  centralized  system  to  perform  engineering 
integration,  overall  station  analysis  and  assessments.  A design 
engineering  capability  is  retained  to  perform  routine  design 
changes  to  sustain/maintain  the  Space  Station  operational  status. 
Major  design  efforts  would  be  contracted  to  the  evolution/growth 
development  contractor.  This  would  especially  be  effective  for 
major  block  engineering  changes.  Utilizing  evolution/growth 
contractor  representatives  as  part  of  the  sustaining  engineering 
contract  team  will  also  keep  the  growth  contractor  fully  involved 
and  aware  of  ongoing  sustaining  changes  and  analysis. 

In  consideration  of  the  long  term  operation  phase  and  initial 
transition,  this  is  the  recommended  option.  It  has  the  advantage 
of  providing  a separate  management  system  and  teams  dedicated  to 
operational  sustaining  engineering.  Also,  it  eliminates  the 
possibility  of  growth  development  work  being  partially  funded  by 
sustaining  engineering  budgets.  Major  development  work  will  be  a 
separate  contract  and  must  be  fully  funded  on  its  own.  Sustain- 
ing engineering  will  be  dedicated  to  maintaining  an  established 
capability  by  correcting  service  revealed  deficiencies  and 
improving  systems  performance,  whereas,  evolution/growth  will  be 
developing  new  capabilities  funded  by  newly  approved  budgets. 
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OPTION  AREA 


SPACE  STATION  FLIGHT  SYSTEMS 


Option  1 Option  2 


Work  Package 
Centers 


Feasibility  5 

Flexibility  2 

User  Friendly  1 

Mgmt  Effective  2 

Cost  Effective  2 

Performance  3 

Safety  2 

Total  17 


Combined  with 
Evo lut ion / Growth 

3 

4 
4 
4 

3 

4 

5 
27 


Option  3 

Centralized 
With  Separate 
Evolution/Growth 
Lingage 

4 

4 

4 

4 

4 

5 
4 

29 
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Internationals 


Option  1.  Pull  partnership  role  in  space  station  operations. 

Option  2.  Separate  allocation  with  space  station  operations 
controlling  interfaces  and  safety. 

Option  1)  Full  Partnership  - In  a shared  partnership  role 
management  effectiveness  is  significantly  low;  changes  affecting 
the  space  station  require  more  mutually  reached  approvals  and  a 
sharing  in  the  decision  processes.  Cost  restraints  from  each 
partner  may  have  restrictive  impacts  on  the  other  partner  where 
enhancements  or  improvements  may  be  involved.  The  amount  of 
commonality  in  designed  hardware  and  software  (foreign  contract- 
ed) is  expected  to  be  low  which  further  diminishes  the  rationale 
in  a full  partnership  role. 

Option  2)  Dser  Role  - Option  2 is  the  preferred  option.  Each 
partner  has  a greater  autonomous  role  within  the  allowance  of 
safety  and  interface  controls  from  space  station  operations 
management.  Each  party  has  greater  flexibility  in  the  changes 
made  to  their  respective  elements.  Management  effectiveness  is 
greater  within  the  realm  of  each  partner's  responsibility. 
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OPTION  AREA 


INTERNATIONALS 


Feasibility 
Flexibility 
User  Friendly 
Management  Effective 
Cost  Effective 
Performance 
Safety 
Total 


Option  1 
Partnership 

2 

2 

4 

2 

2 

2 

4 

18 


Option  2 
User  Role 

5 

4 

3 

5 
5 

4 
4 

30 


\ 
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Osera 

Option  1.  Oser  interfaces  controlled  by  their  own  management 
with  minimum  Space  Station  constraints. 

Option  2.  Oser  interfaces  controlled  by  a NASA  user  support 
group. 

Option  1 ) Autonomous  - Option  one  leaves  a lot  to  be  desired 
because  of  impediments  it  presents  to  standardizing  Space  Station 
payload  interfaces.  It  creates  an  environment  of  payload  driven 
interfaces  that  could  result  in  considerable  customizing. 

Overall  Space  Station  performance  would  not  be  as  effectively 
managed.  Even  though  it  is  desirable  to  be  as  attractive  to 
potential  payload  customers  as  possible,  consideration  must  be 
given  to  minimizing  Space  Station  interface  changes  for  the 
economic  and  performance  benefit  to  all  payload  customers.  Also, 
a more  standardized  approach  to  interfaces  facilitate  performance 
and  safety  integrity. 

Option  2)  Controlled  - Option  two  optimizes  the  balance  between 
user  unique  interface  requirements  and  Space  Station  standards  by 
establishing  a NASA  user  support  group  with  participation  from 
the  user  community.  This  approach  establishes  a single  area  of 
contact  within  NASA  and  affords  the  means  for  an  integrated 
resolution  of  interface  conflicts.  This  results  in  improved 
understanding  of  Space  Station  operating  standards  and  con- 
straints. Overall  performance  of  Space  Station  and  standard 
interfaces  will  be  more  efficiently  maintained  for  user  utiliza- 
tion. 
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OPTION  AREA 


USER  AUTONOMY 


Feasibility 
Flexibility 
User  Friendly 
Management  Effective 
Cost  Effective 
Performance 
Safety 
Total 


Option  1 
Autonomous 

3 

4 
4 
2 
2 
2 
2 

19 


Option  2 
Controlled 

4 

3 

3 

4 
4 
4 
4 

26 
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Space  Station  Support  Systems.  Support  systems  for  Space  Station 
include  all  unique  systems  required  to  support  in-flight  opera- 
tions and  prelaunch  and  post  landing  processing.  This  includes 
such  systems  and  equipment  as  command  and  control  stations, 
handling  GSG,  servicers,  automated  checkout  systems,  training, 
simulators,  SSE,  TIMS,  and  others. 

There  are  basically  three  options  in  performing  operations 
sustaining  engineering  for  Space  Station  support  systems:  1)  Use 
developers,  2)  Centralize  under  one  SG  contractor,  3)  Distribute 
unique  systems  to  appropriate  operations  centers  and  centralize 
common/distributive  systems  under  the  flight  systems  SE  contrac- 
tor or  appropriate  operations  center. 

Option  1 is  clearly  not  recommended  for  the  same  reasons  that 
were  identified  for  not  retaining  the  prime  developers  for  SE  of 
the  Space  Station  flight  systems.  Those  reasons  were  primarily 
related  to  higher  SE  costs  over  the  long  run,  development  mental-' 
ity  driving  unnecessary  operational  changes,  and  management 
inefficiency  created  by  multiple  SE  contractors. 

Option  2 is  not  considered  practical  due  to  the  large  diversity 
of  systems  and  transitional  impacts  between  established  opera- 
tions centers. 

Option  3 would  centralize  SE  of  only  those  systems  with  high 
commonality  and  wide  distributions  under  the  centralized  flight 
systems  SE  contractor.  This  would  include  such  systems  as  SSE 
and  TMIS.  Unique  systems  such  as  servicers,  handling  GSE, 
simulators,  training,  GDMS;  etc.,  should  be  sustained  by  the 
operations  center  having  predominant  use.  For  example,  GDMS 
sustaining  engineering  would  be  performed  by  the  Kennedy  Space 
Center  payload  ground  operations  contractor.  Advantages  of 
implementing  Option  three  are:  provides  SE  support  closest  to 

the  location  of  predominant  use,  thereby  improving  response  time 
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to  changes  and  better  lead-time  support;  more  efficient  manpower 
utilization-minimum  duplication;  and  minimum  transition  impacts. 
Therefore,  Option  3 is  the  recommended  approach  for  Space  Station 
support  systems. 
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OPTION  AREA:  SPACE  STATION  SUPPORT  SYSTEMS 


Feasibility 
Flexibility 
User  Friendly 


Option  1 
Distributed 


Option  2 
Centralized 


Option  3 
Mixed 


2 


1 


4 


2 3 4 

14  3 


Management  Effective 


Cost  Effective 


Performance 

Safety 


2 

1 

3 

3 


2 

2 

3 


3 

4 
4 


19 


26 


Total 


14 


4.5.2  Risk  Acceptance  and  Planning 


There  are  two  areas  of  risk  acceptance  and  planning  that  need  to 
be  reviewed  and  options  considered  as  they  relate  to  sustaining 
engineering  during  the  operational  life  of  the  Space  Station. 

They  are:  Prelaunch  Verification  and  Contingency  Planning. 

Prelaunch  Verification.  There  are  two  basic  Prelaunch  Verifi- 
cation options  involving  levels  of  risk  and  planning  that  affect 
sustaining  engineering.  One  option  requires  extensive  prelaunch 
verification  that  includes  a thorough  flight  hardware  checkout  at 
the  launch  site  prior  to  launch.  The  other  option  is  described 
as  "ship  and  shoot"  and  requires  minimum  checkout  and  verifica- 
tion once  the  hardware  has  left  the  developers  location. 

Option  1)  Thorough  Prelaunch  Verification  - Thorough  prelaunch 
verification  necessitates  a higher  initial  investment  in  verifi- 
cation equipment  such  as  simulators,  test  sets,  and  models  as 
well  as  more  available  facility  space.  However,  from  a sustain- 
ing engineering  viewpoint,  it  should  be  cost  effective  over  the 
long  term  since  a larger  number  of  deficiencies  or  discrepancies 
would  be  identified  prior  to  placing  hardware  or  software  in 
service,  thereby  minimizing  costly  on-orbit  sustaining  engineer- 
ing changes.  Also,  the  availability  of  ample  verification 
equipment  and  software  would  facilitate  future  on-orbit  sustain- 
ing engineering  enhancements  and  other  modifications.  Another 
benefit  of  this  approach  is  the  lower  risk  involved  in  achieving 
the  desired  results  of  specific  changes  since  a more  thorough 
evaluation  prior  to  launch  is  afforded.  Also,  it  would  be  more 
advantageous  in  providing  real  time  engineering  and  operational 
support  required  for  problem  resolutions.  Planning  accuracy 
would  be  improved  as  a result  of  the  ground  capability  to  better 
verify  timeliness  and  procedures  and  train  personnel  required  to 
implement  modifications.  Over  the  life  of  the  Space  Station,  the 
greater  initial  ground  time  and  hardware  investment  should  be 
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more  than  offset  by  the  savings  of  expensive  on-orbit  time  and 
on-orbit  trial  and  error  lessons. 

Option  2)  "Ship  and  Shoot"  - This  option,  described  as  ship  and 
shoot,  would  obviously  lower  initial  prelaunch  investment  cost, 
but  would  incur  a greater  risk  of  required  follow-up  effort  after 
launch.  The  one  time  cost  saving  on  verification  hard- 
ware/software and  facility  space  on  the  front  end  of  the  program 
seems  ineffective  in  terms  of  the  increased  cost  potential  over 
30  years  of  station  operation  due  to  inefficiency  of  implementing 
sustaining  engineering  changes.  The  utilization  of  simulators, 
test  sets,  and  models  not  only  to  comprehensively  verify  baseline 
program  elements  prior  to  launch,  but  to  verify  future  modifica- 
tions appears  to  make  the  ship-and-shoot  option  with  no  thorough 
prelaunch  verification  a poor  choice  from  a long  term  sustaining 
engineering  viewpoint.  A relative  comparison  of  these  two 
options  is  shown  as  follows: 
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OPTION  AREA:  PRELAUNCH  VERIFICATION 


Option  1 

Through 

Verification 


Feasibility  5 

Flexibility  5 

User  Friendly  1 

Management  Effective  5 

Cost  Effective  4 

Performance  4 

Safety  4 

Total  28 


Option  2 

Ship  and 
Shoot 

3 

2 

5 

1 

2 

2 

2 

17 
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Contingency  Planning.  Basically,  there  are  two  extremes  in 
approaching  contingency  planning.  There  is  the  one  option  of 
detail  plans  and  procedures  and  the  other  option  of  real  time 
adaptation  to  whatever  anomaly  situation  may  occur. 

Option  1)  Planned  - Detail  planning  and  preparation  for  con- 
tingencies requires  a higher  level  of  sustaining  engineering 
effort.  A thorough  analysis  of  failures  and  hazards  must  be  made 
on  all  changes  and  provided  to  operations  and  safety  personnel 
for  review  and  planning.  A group  of  engineers  separate  from  the 
designers,  but  within  the  sustaining  engineering  function,  would 
be  required  for  this  option.  The  slightly  higher  cost  incurred 
would  well  be  worth  the  lower  risk  produced  by  an  approach  that 
is  well  documented  analytically  with  proper  backup  procedures 
that  minimize  impacts  due  to  anomalous  performance.  The  need  for 
deviation  waivers  would  be  minimized. 

Option  2 ) Adaptation  - Option  two  would  concentrate  more  on 
adapting  to  anomalous  performance  in  real-time.  Even  though  less 
effort  would  be  expended  on  front-end  planning,  there  would  be  a 
greater  need  for  involvement  of  engineering  on  a real-time  basis 
during  critical  operations  as  opposed  to  a less  intense  on-call 
approach.  Therefore,  there  would  probably  be  insignificant 
engineering  cost  savings,  but  there  would  be  a higher  risk  to 
operations.  Also,  with  less  rigorous  planning  for  contingencies, 
the  potential  for  documentation  and  configuration  problems  due  to 
more  real  time  changes  would  increase.  These  two  options  are 
rated  as  follows: 
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OPTION  AREA:  CONTINGENCY  PLANNING 


Feasibility 
Flexibility 
User  Friendly 
Management  Effective 
Cost  Effective 
Performance 
Safety 
Total 


Option  1 
Planned 
5 
2 
2 
5 
4 

4 

5 
27 


Option  2 
Adaptation 
1 
4 
4 
1 
2 
2 
1 
15 
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Design  Factors.  There  are  certain  design  factor  options  that 
affect  the  sustaining  engineering  functions  for  Space  Station  and 
for  flight  and  ground  support  systems.  These  factors  are: 
Automation,  Evolution/Growth,  Supportability /Maintenance,  and 
Commonality. 

Automation.  To  appreciate  the  effect  automation  may  have  on 

sustaining  engineering  it  is  instructive  to  look  at  the  extremes 
of  a highly  automated  operations  verses  a manual  operation  with  no 
automation.  Highly  automated  operations  imply  technically  complex 
systems  with  a high  degree  of  design  sophistication  involving 
robotics  and  other  advanced  technology.  This  requires  a higher 
engineering  skill  level  resulting  in  higher  costs  for  sustaining 
engineering,  even  though  there  could  be  a very  significant  cost 
reduction  to  operations  because  of  less  dependence  on  the  human 
element.  Also,  there  would  be  an  improvement  in  safety  especially 
where  a non-human  mechanical  means  of  .accomplishing  hazardous  ■ 
operations  could  be  utilized.  Conversely,  a manual  operation  with 
a high  dependence  on  man  would  simplify  many  systems  resulting  in 
a lower  sustaining  engineering  skill  level.  It  should  be  noted 
that  even  in  the  case  of  a highly  automated  robotic  operations, 
consideration  is  not  given  to  the  total  elimination  of  man's 
presence  which  would  open  up  a wide  array  of  different  trade-offs. 

The  approach  here  is  to  examine  the  effect  on  sustaining  engineer- 
ing for  the  long  term  with  highly  automated  systems  and  less  de- 
pendence on  man,  even  though  he  is  still  present,  verses  a non- 
automated  system  with  high  dependence  on  man.  The  most  beneficial 
approach  considering  both  extremes  is  to  automate  to  the  extent 
only  of  protecting  man  from  the  more  risky  procedures  and  to  the 
extent  that  systems  can  be  developed  that  would  not  overly  compli- 
cate long  term  engineering  and  maintenance  support.  Appendix  H 
describes  an  approach  used  by  Ocean  Systems  Engineering. 
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OPTION  AREA:  AUTOMATION 


Feasibility 
Flexibility 
User  Friendly 
Management  Effective 
Cost  Effective 
Performance 
Safety 
Total 


Option  1 
Automate 
5 
2 
2 

3 
5 

4 
2 

23 


Option  2 
Manual 
1 
5 

3 
2 
1 
2 

4 

II 
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Evo 1 ut ion / Growth 


Two  approaches  toward  the  growth  and  evolution  of  the  Space 
Station  ares  1)  plan  well  in  advance  by  factoring  it  into  the 
design  and  by  appropriate  scarring  during  the  fabrication,  or  2) 
adapting  to  whatever  growth  evolves  at  whatever  time. 

A well  planned  scheme  for  the  evolution  and  growth  of  the  Station 
has  many  advantages  for  sustaining  engineering.  It  minimizes 
modification  design  and  implementation  impacts  and  provides  for  a 
better  managed  approach  for  making  enhancement  changes.  Knowing 
what  growth  is  planned  allows  sustaining  engineering  to  implement 
changes  without  creating  problems  for  that  growth.  As  a conse- 
quence, this  results  in  lower  cost,  better  reliability  and  more 
accurate  change  assessments  during  mature  operations. 

If  the  second  approach  of  adapting  to  growth  as  it  materializes 
is  used,  it  will  require  a higher  sustaining  effort  because  of 
the  necessity  to  redo  or  undo  modifications  that  impede  growth. 
Also,  sustaining  engineering  will  be  more  developer  dependent. 

The  final  results  for  sustaining  engineering  will  be  higher  cost, 
less  reliability  and  less  accurate  configuration  data. 
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OPTION  AREA:  EVOLUTION /GROWTH 


Feasibility 
Flexibility 
User  Friendly 
Management  Effective 
Cost  Effective 
Performance 
Safety 
Total 


Option  1 
Planned 
2 
2 
5 
5 
5 
5 
4 

28 


Option  2 
Adaptation 
5 
5 
1 
1 
1 
1 
2 

16 


V. 
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Commonality 


Commonality  of  hardware  and  software  where  feasible  can  serve  to 
reduce  sustaining  engineering  cost  by  allowing  the  consolidation 
of  resources.  Commonality  to  the  Orbital  Replacement  Dnit  (0R0) 
level  is  already  a key  driver  in  the  SSP  design.  Further  benefit 
can  be  realized  by  achieving  commonality  in  flight  and  ground 
support  systems.  For  example,  simulators  and  checkout  systems 
will  be  required  to  support  both  flight  and  ground  functions. 

If  a large  degree  of  commonality  is  developed  in  systems  such  as 
Taverns  and  Ground  Data  Management  System  ( GDMS ) it  would  allow 
for  consolidation  of  operations  functions  such  as  sustaining 
engineering  and  logistics.  Commonality  could  also  be  extended  to 
include  GSE,  models,  trainers,  control  centers,  and  data  bases. 

A high  level  of  commonality  would  offer  significant  opportunity 
for  consolidation  during  the  operations  era  with  a corresponding 
reduction  in  cost. 

The  alternate  approach  is  independent  development  with  no  push 
for  commonality.  Unique  systems  and  equipment  will  be  the  result 
with  minimum  opportunity  to  consolidate  operations  functions. 


OPTION  AREA:  COMMONALITY 


Feasibility 
Flexibility 
User  Friendly 
Mgmt  Effective 
Cost  Effective 
Performance 
Safety 
Total 


Option  1 

Commonality 

3 
5 

4 

5 
5 
5 
4 

3T 


Option  2 

Independent 

Design 

5 

1 

2 

1 

1 

1 

2 

13 
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Supportability /Maintainability 


An  important  supportability /maintenance  factor  to  sustaining 
engineering  is  the  level  of  diagnostic  capability.  A high  level 
of  diagnostic  capability  offers  better  analyses  of  trends  that 
may  lead  to  problems  or  failures  and  consequently  results  in  a 
more  effective  sustaining  engineering  and  maintenance  effort. 
Potential  problems  can  be  detected  and  corrected  either  by 
maintenance  procedures  or  engineering  changes  before  operational 
impacts  are  incurred.  An  important  consideration  in  implementing 
a high  level  diagnostic  capability  is  not  to  overly  complicate 
the  systems  and  hardware  to  be  diagnosed.  This  could  exaggerate 
the  very  condition  that  one  is  attempting  to  improve.  To  mini- 
mize this  effect  it  is  important  that  to  the  extent  possible 
diagnostic  components  be  separate  and  portable  while  only  sensors 
and  minimum  diagnostics  be  incorporated  into  the  operating 
hardware.  <Ref.  Appendix  H,  An  overall  review  of  the  development 
of  teleoperated  systems  and  sustaining  engineering  programs  in 
the  Deepwater  Industry). 

The  other  option  is,  to  provide  very  little  diagnostic  capability 
which  would  save  initial  cost,  but  would  increase  cost  and  risk 
over  the  long  term  because  of  less  effective  sustaining  engineer- 
ing and  maintenance  effort  and  more  operational  impacts.  Even 
though,  there  are  less  components  to  fail  or  give  erroneous  data 
with  this  approach,  a better  approach  is  to  maximize  the  port- 
ability of  diagnostic  components  and  retain  a high  level  of 
diagnostic  capability  while  preserving  system  reliability. 
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OPTION  AREA:  SUPPORTABILITY/MAINTAINABILITY 


Option  1 
High 

Diagnostics 


Feasibility  2 

Flexibility  5 

User  Friendly  4 

Mgmt  Effective  5 

Cost  Effective  4 

Performance  5 

Safety  4 

Total  29 


Option  2 
Low 

Diagnostics 

4 

1 

2 

1 

2 

1 

2 

13 
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APPENDIX  A 


SUSTAINING  ENGINEERING 

FUNCTIONAL  DESCRIPTION  OUTLINE 
Appendix  A 

SUSTAINING  ENGINEERING 
FUNCTIONAL  DESCRIPTION  OUTLINE 

This  section  is  an  outline  definition  of  the  sustaining  engi- 
neering functions  necessary  to  support  operations  of  the  Space 
Station  Program.  These  functions  are  replicable  to  any  area  of 
sustaining  engineering  organizations.  The  scope  of  this  effort 
is  flight  hardware  and  software,  ground  systems  hardware  and 
software,  ground  support  equipment  and  ground  processing  soft- 
ware, and  support  to  customer  integration.  The  sustaining 
engineering  functional  area  includes: 

Performing  the  analysis  and  engineering  necessary  to 
maintain  and  enhance  the  Space  Station  Program  orbital  and 
ground  support  program  elements. 

Designing,  building,  and  supporting  the  installation  and 
integration  of  approved  modifications  to  the  program 
elements. 

Developing  and  maintaining  integration  and  verification 
requirements  for  flight  systems,  ground  systems,  and  the 
interfaces  to  customer  systems,  transportation  systems,  and 
institutional  tracking,  data  relay,  and  ground  data  commu- 
nications systems. 
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Performing  the  day-to-day  management  of  approved  program 
configurations  and  supporting  the  overall  Configuration 
Management  and  control  program. 

FONCTION  OOTLINE: 

1.  Planning  and  Management 

2.  Systems  Analysis 

3.  Design  Engineering 

4.  Engineering  Integration  and  Verification 

5.  Documentation 
SOB  FUNCTIONS : 

1.  Planning  and  Management 

A.  Planning  and  Scheduling 

B . Budget  Management 

C.  Contract  Management 

D.  Resource  Management 

E.  Manage  Station  System  Advanced  Technology  Programs  - As 
Assigned 

F.  Evolution  and  Growth  Management  - (Space  Station  Im- 
pacts ) 

2.  Systems  Analysis 

A.  Flight  Certification  Engineering  Analysis  (from  customer 
recommendations  and  station/platform  system 
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modifications  and  enhancements) 

B.  Systems  Performance  Analyses  - Conduct  Trend  Analyses 
and  Evaluate  Test  Data 

C.  Provide  Analyses  of  System  Performance  Degradations 

D.  Identify  Requirements  for  Operational  Performance 
Enhancements 

E.  Failure  Analyses 

F.  Mass  Properties  Analyses  and  Configuration  Analysis 

G.  Support  the  Feasibility  and  Supportability  Analyses  of 
Proposed  Enhancements  and  Modifications 

H.  Technical  Risk  Assessments  - for  flight  and  ground 
support  hardware  and  software  systems 

1.  Criticality  Assessments 

2.  Failure  Mode  and  Effects  Analyses 

3.  Single  Point  Failure  Analysis 

4.  Safety  and  Hazard  Analyses  and  Assessments 

5.  End-to-End  Analysis 

6.  Sneak  Circuit  Analysis 

7.  Control  Logic  Reviews 

8.  Feasibility 

9.  Availability 

10.  Commonality 

11.  Maintainability 

12.  Operability 

13.  Cost 

14.  Schedule 

I.  Environmental  Analysis  and  Control 
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1.  Vibration  Analysis 

2.  Acoustical  Analysis 

3.  Thermal  Loads  Analysis 

4.  RFI  Analysis 

5.  Load  Stress  Analysis 

3.  Design  Engineering 

A.  Design  and  Engineering  of  Flight  Systems  and  Ground 
Support  Systems 

Enhancements /Modifications 

1.  Conceptual,  Preliminary,  and  Detailed  Design 
Products  (includes  documentation,  analyses,  and 
reviews . ) 

2.  Integrated  Design  Reviews 

3.  Specifications,  Drawings,  Requirements 

4.  Design  Criteria 

5.  Design  Verification  Requirements 

6.  O&M  Documentation 

7.  Installation/Modification  Requirements 

8.  Preparation  and  Maintenance  of  "As-Built H Drawings, 
Specifications  and  S/W  Source  Code  Listings 

9.  Systems  Reconfiguration  and  Installation 
Requirements.  Also  Includes  Payload 
Installation/Removal  Requirements.  Includes 

Schematics,  Installation/Removal  Instructions  and 
Software  Products. 

10.  Transportation  Configuration  Design 

B.  Design  of  Test  Article  Hardware,  Software,  and  Ground 
Support  Equipment 

4.  Engineering  Integration  and  Verification 

A.  Modification  Enhancement  Hardware  and  Software 
Integration  and  Implementation 

1.  Flight  Systems 
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2 . Ground  Systems 

3.  Customer  Systems  to  Flight/Ground  Systems 

4.  Flight /Ground  Systems  to  Transportation  Systems 

5.  Flight /Ground  Systems  to  Institutional  Tracking, 
Data  Relay,  and  Ground  Data  Communications  Systems 


B.  Customer  to  System/ Subsystem  Integration,  Verification, 
and  Compatibility  Assessments 


C.  Verification  Testing  Planning 

1.  Test  Objectives  and  Requirements 

2.  Evaluation  Criteria 

3.  Test  Procedures  and  Plan 

4.  Training 

5.  Scheduling 


D.  Support  to  Verification  Testing  (testing  performed  by 
operations) 


E.  Customer-System  Interface  Engineering.  Includes 
Customer-System  Interface  Designs  as  Required 


F.  "Build"  Process 

1.  Make  or  Buy  Decisions 

2 . Procurement  Support 

a . Hardware 

b.  Software 

c.  Materials 

d.  Services 

G.  Real-Time  Engineering  Support  to  Operations 

1.  Engineering  for  Anomaly  Resolution 

2.  Systems  Performance  Monitoring 

3.  Engineering  for  Critical  Operations 

H.  Integrate  and  Coordinate  Evaluations,  Assessments, 
Analysis,  and  Anomaly  Resolution 

5.  Documentation 

A.  Maintain  and  Update  Flight  Hardware  ICD's 
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B.  Maintain  and  Update  Flight  S/W  Source  Code  Listings 

C.  Maintain  and  Update  Ground-Flight  Systems  ICD's 

D.  Maintain  and  Update  Ground  System  S/W  Source  Code 
Listings 

E.  Maintain  and  Update  Architecture  Control  Documents 
( ACDs ) 


F.  Design  Documentation 

G.  Configuration  Status  and  Updates  (Data  Base  Products) 

H.  Mass  Property  Documentation 

I . Performance  Trend  and  Prediction  Reports 

J.  Design  Review  Packages 

K.  Analysis  Reports 

L.  Flight  Certification  Status 

M.  Commonality  Identification  and  Status 

N.  Access  Requirements  to  Customers,  Space  Station  Ele- 
ments , and 

Support  Systems 

O.  Updates  to  Controlled  Documentation  is  Approved  by 
Configuration  Management 
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APPENDIX  B 


CONFIGURATION  MANAGEMENT 


FUNCTIONAL  DESCRIPTION  OUTLINE 


CONFIGURATION  MANAGEMENT 

FUNCTIONAL  DESCRIPTION  OUTLINE 

This  section  is  an  outline  description  of  the  configuration 
management  Functions  required  to  support  the  Space  Station 
Program.  These  functions  are  replicable  to  any  level  of  config- 
uration management  Systems. 

Day  to  day  activities  are  a mixture. 

Very  Top-Level  function  can  be  strategic  - i.e..  Bilateral 
Agreements  to  change  the  Fundamental  Configuration  of  the  Space 
Station  Flight  or  Support  Systems. 

FUNCTION  OUTLINE: 

1.  Configuration  Identification 

2.  Configuration  Control 

3.  Configuration  Verification  (Auditing) 

4.  Configuration  Accounting 
SUBFUNCTIONS : 

1.  Configuration  Identification 

A.  Selecting  End  Items  of  Hardware  and  Software  to  Come 
Under  Configuration  Control 

B.  Develop  and  Maintain  Baseline  Identification  of  H/W  and 
S/W  Under  Configuration  Control 

C.  Develop  and  Maintain  Engineering  Documentation 

1.  Prepare  and  Maintain  H/W  & S/W  Specifications, 
Drawings,  and  S/W  Source  Code  Listings 

2.  H/W  & S/W  Engineering  Documentation  and  Computer 
Program  Media  Records  and  Releases 
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2.  Configuration  Control 

A.  Controlling  H/W  & S/W  Such  That  Demonstrated  Physical 
Status  and  Performance  Satisfy  Mission,  Safety,  and 
Security  Requirements 

B.  Managing  Changes  to  the  Baseline  System  Through  a 
Formal  Review  and  Approval  Process  Prior  to  Directing 
H/W  & S/W  Changes 

C.  Closing  Out  Configuration  Change  Directives  Upon 
Completion  of  the  Configuration  Verification  and 
Configuration  Accounting  Processes 

3.  Configuration  Verification  (Auditing) 

A.  Conduct  Reviews  to  Assure  that  the  Design  of  the  Changes 
to  the  Baseline  Configuration  Satisfies  Approved 
Requirements  (Mission,  Safety,  & Security) 

B.  Conduct  Reviews,  Tests,  Inspections,  etc.,  to  Assure 
that  H/W  or  S/W  End  Items  Conform  to  the  Released  Design 
Documentation 

C.  Conduct  Reviews,  Tests,  Inspections,  etc.,  to  Assure 
that  the  Modifications  Have'  Been  Incorporated  in 
Accordance  with  the  Configuration  Change  Directive 
(i.e..  Verify  "As-Built"  is  the  Same  as  "As-Designed") 

D.  Conduct  Periodic  Reviews  and  Audits  to  Verify  that  the 
Change  Control  Process  is  Effective 

4.  Configuration  Accounting 

A.  Establish  and  Maintain  a Data  Collection  and  Storage 
System  Which  Provides  for  Tracking  and  Auditing  the 
Change  Control  Documentation.  These  Include  Change 
Requests,  Disposition  Actions  for  Change  Requests,  and 
Verification  Reports 

B.  Provide  Approved  Inputs  to  the  System(s)  Containing  the 
Identification  of  the  Baseline  Systems 

C.  Manage  Program  Configuration  Data  Base(s) 
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Sustaining  Engineering  and  Configuration  Control 
Scenarios /Schemes  for  the  Space  Station 
Program  Operational  Era 

Glenn  R.  Parker 


INTRODOCTION 

After  the  Space  Station  Program  (SSP)  becomes  fully  operational, 
the  methods  by  which  the  engineering  changes  associated  with  SSP 
maintenance,  modifications,  upgrades,  and  overall  evolution  are 
handled  and  managed  will  be  similar  to  those  methods  that  are 
implemented  during  the  SSP  Design,  Development,  Test,  and 
Evaluation  (DDT&E)  phase,  but  the  management  scheme  for  these 
methods /functions  should  be  different  than  that  employed  for  the 
early  DDT&E  phase  of  the  program.  Required  management  and 
operational  response  time,  efficiency,  and  cost  effectiveness 
will  dictate  that  an  evolution  in  sustaining  engineering  and 
change  management  schemes  take  place  that  will  allow  such 
systems  to  be  operationally  oriented  and  streamlined  in  order 
for  the  program  to  cope  efficiently  with  the  multifaceted 
scenarios  that  will  exist  during  the  SSP  operational  era.  These 
scenarios  will  probably  be  different  than  those  faced  early  in 
the  program  due  to  the  increased  complexity  in  SSP  subsystems/ 
systems,  operations,  and  interrelationships/  interdependence 
with  other  prograro/agency  elements.  This  treatise  will  describe 
typical  engineering  change  scenarios  that  might  occur  during  the 
SSP  operational  era,  and  will  also  describe  operational  change 
management  and  sustaining  engineering  schemes  that  could  be 
utilized  to  handle  these  scenarios. 

ENGINEERING  CHANGE  SCENARIO  DESCRIPTION 

For  the  purposes  of  this  paper,  two  typical  engineering  change 
scenarios  that  might  occur  during  the  SSP  operational  era  are 
considered.  It  is  realized  that  other  scenarios  may  exist  which 
will  be  different  than  those  described  herein,  or  that  a combi- 
nation of  scenarios  may  exist  that  embodies  some  elements  of 
those  described  herein.  However,  these  two  scenarios  are  felt 
to  be  representative  of  the  boundary  conditions  that  will  exist 
for  such  changes  that  may  occur  during  this  era.  The  two  chosen 
scenarios  are: 

(1)  An  engineering  change  that  affects  multi  program/agency 
elements  such  as  the  Space  Station  Program  elements.  Interna- 
tional elements  that  are  a part  of  the  SSP,  National  Space 
Transportation  System  (NSTS)  elements  (e.g.,  Orbiter),  and  other 
program/agency  elements  such  as  users  (customers),  the  Tracking 
Date  Relay  Satellite  System  (TDRSS),  and/or  the  Global  Position- 
ing System  (GPS).  Examples  of  such  changes  are: (a)  A change  to 
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the  basic  station  electrical  power  scheme  involving  wiring  size 
changes,  electrical  frequency  changes,  load  carrying  capabili- 
ties, etc.,  (b)  changes  in  data  rate/channel  requirements,  high 
resolution  video  requirements,  or  uplink/downlink  data  require- 
ments, and  (c)  a requirement  for  Orbiter  control  of  the  Station 
Remote  Manipulator  System.  Such  changes  would  not  only  affect 
0.  S.  Space  Station  Element  subsystems /systems,  but  could  affect 
international  element,  customer,  Orbiter,  TDRSS,  and/or  GPS 
subsystems /systems,  dependent  upon  the  example  considered. 

(2)  An  engineering  change  that  affects  only  the  U.S.  supplied 
elements  of  the  SSP  and  does  not  involve  any  other  supplied 
elements  of  the  SSP  or  any  other  elements  of  various  pro- 
grams/agencies. An  example  of  such  a change  might  be  a change 
involving  the  addition/upgrade  of  a work/maintenance  bench  in 
the  U.S.  Laboratory  or  Habitation  Module. 

For  each  of  these  scenarios,  a proposed  operational  era  engi- 
neering change  management  and  sustaining  engineering  scheme  will 
be  presented  and  described. 

OPERATIONAL  CHANGE  MANAGEMENT  AND 
SUSTAINING  ENGINEERING  SCHEME 

Typically,  early  phases  of  any  program  utilize  a change  manage- 
ment and  sustaining  engineering  scheme  that  involves. the  program 
manager,  the  program's  project  managers,  a configuration  manage- 
ment team,  a systems  engineering  and  integration  (SE&I)  team, 
project  systems  engineering  experts,  and  a distributed  change 
evaluation  process  to  evaluate,  disposition,  and  implement 
program/project  change  requests  (CR's).  The  program/  project 
managers  usually  have  all  of  the  approval /disapproval  authority 
for  the  purposes  of  dispositioning  such  CR's,  and  operations 
personnel  are  usually  only  a part  of  the  submittal  and/or  the 
change  evaluation/  implementation  process.  As  such,  operations 
personnel  have  very  little  control  over  their  own  destiny,  and 
operational  considerations,  including  cost,  often  are  not 
properly  considered  during  the  change  control/manageroent  pro- 
cess. During  the  operational  era  of  the  SSP,  and  other  pro- 
grams, a change  management  and  sustaining  engineering  scheme 
should  evolve  to  one  that  is  primarily  controlled  by  operations 
personnel  via  a single  Program  Operations  Manager,  who  is  in 
charge  of  both  flight  and  ground  operations  for  the  program(s). 
The  appeal  route  for  such  a scheme  would  be  from  the  Program 
Operations  Managers  to  an  Associate  Administrator  for  Opera- 
tions. A proposed  top-level  organizational  structure  for  such  a 
scheme  is  depicted  in  Figure  1.  Such  a structure  would  replace 
the  normal  structures  that  exist  during  the  early  phases  of 
various  programs.  The  operational  era  structure  would  make  a 
change  management  and  sustaining  engineering  scheme  more  opera- 
tionally controlled  and  oriented,  in  tune  with  operational 
needs,  more  streamlined,  and,  hopefully,  more  cost  effective. 
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In  a program's  operational  era,  it  would  be  desirable  if  all 
programs  could  evolve  their  organizational  structure,  change 
management  schemes,  and  sustaining  engineering  schemes  along 
such  a philosophy  to  facilitate  inter-program  compatibility. 

With  such  a philosophy  in  place,  an  engineering  change  and/or 
sustaining  engineering  effort  that  affected  the  SSP  only  would 
be  supported  by  the  "generic”  change  management  and  sustaining 
engineering  scheme  shown  in  Figure  2.  An  example  of  such  a 
change,  as  previously  mentioned,  might  be  an  addition  of  an/or 
upgrade  to  a work/maintenance  bench  in  the  U.S.A.  supplied 
Laboratory  or  Habitation  Modules. 

If  a change  affected  multiple  programs,  such  as  the  SSP,  the 
NSTS  program,  and  the  Canadian  (International)  program,  the 
"generic”  change  management  and  sustaining  engineering  scheme 
would  be  expanded,  as  shown  in  Figure  3,  to  encompass  the  three 
programs.  An  example  of  such  a change  would  be  one  that  re- 
quired a modification  to  allow  for  control  of  the  Space  Station 
Manipulator  Arm  (MRMS ) from  the  Orbiter  Aft  Flight  Deck. 

Finally,  if  a change  affected  all  programs  that  may  be  interre- 
lated with  the  SSP,  during  the  operational  era,  the  "generic" 
change  management  and  sustaining  engineering  scheme  would  be 
further  expanded,  as  shown  in  Figure  4. 

The  only  differences  between  the  three  schemes  are  the  number  of 
participants  involved  and  the  magnitude  of  the  required  integra- 
tion effort  among  the  various  involved  programs.  However,  the 
same  basic  eleven  step  process  would  be  followed  for  all  of  the 
depicted  schemes.  In  order  to  describe  the  basic  eleven  step 
process  of  these  change  management  and  sustaining  engineering 
schemes,  the  example  depicted  by  Figure  3 is  chosen.  This 
example  was  chosen  because  it  adequately  depicted  the  complexity 
associated  with  multi-program  interrelationships,  while  at  the 
same  time  remaining  simple  enough  in  scope  to  allow  the  reader 
to  relate  to  the  "generic"  scheme.  In  describing  the  basic 
eleven  step  process,  it  should  not  be  assumed  that  all  changes 
roust  go  through  the  entire  process.  Some  changes,  such  as 
'quick  turn  changes'  or  changes  to  basic  customer's  hard- 
ware/software, may  be  able  to  skip  some  steps.  These  factors 
would  be  considered  on  a case-by-case  basis.  However,  what 
follows,  is  a basic  description  of  the  eleven  step  process  for 
the  change  example  chosen. 

OPERATIONAL  CHANGE  MANAGEMENT 
AND  SUSTAINING  ENGINEERING  SCHEME 
STEP  DESCRIPTION 


STEP  ♦!  - Requirement  Initiation  - An  engineering  change  could 
be  initiated  by  anyone  from  any  program/agency  at  any  level. 
Such  a change  request  could  be  in  the  from  of  a Program/Project 
Change  Request  (CR),  an  Engineering  Support  Request  (ESR), 
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Engineering  Change  Proposal  (ECP),  or  any  other  program  equiva- 
lent. For  the  purpose  of  this  paper,  a generic  term,  "Change 
Request  (CR)",  will  be  used  to  describe  such  changes. 

When  the  CR  enters  the  system,  a requirements  initiation  team 
would  receive  it  and  perform  the  following  functions: 

A.  The  team  would  determine  whether  the  change  affected  the 
usage  of  the  station  and/or  operations,  whether  the  change 
represented  an  enhancement  to  present  station  design,  or  whether 
the  change  was  needed  to  resolve  a problem  on  board  the  station. 
It  would  also  determine  if  one  or  more  programs/agencies  were 
affected  by  the  CR. 

B.  The  team  would  determine  the  criticality  of  the  change. 

C.  The  team  would  assess  the  change  rationale  and  insure  that 
the  originator  had  included  enough  information  with  the  CR  (e.g. 
design  concepts,  etc.)  to  allow  for  a future  impact  assessment. 

D.  The  team  would  prepare  and  forward  an  Engineering  Support 
Request  ( ESR ) , or  equivalent,  that  reflected  the  original  CR. 

The  ESR  would  be  forwarded  to  the  appropriate  screening  boards, 
where  Step  #2  of  the  process  would  begin. 

STEP  »2  - Screening  Board  - The  screening  boards  would  be 
chaired  by  the  Program  Operations  Managers  or  designate  and 
supported  by  various  operations  discipline  and  SE&I  discipline 
personnel  such  as  logistics  personnel,  customer  (user)  represen- 
tatives, engineering  personnel,  operations  personnel,  manifest 
personnel,  safety  reliability  and  quality  assurance  (SR  & QA) 
personnel,  etc.  Each  program/agency  affected  by  the  change 
would  have  a similar  arrangement.  The  purpose  of  the  screening 
boards  would  be  to  initially  screen  the  change  and  provide  for  a 
preliminary  disposition  in  order  to  keep  unwanted  changes  from 
choking  the  full  assessment  process.  Upon  receiving  the  ESR, 
the  screening  boards  would  perform  the  following  functions: 

A.  The  screening  boards  would  perform  an  initial  validation  of 
the  ESR  to  determine  if  the  change  paper  contained  enough 
information  for  an  assessment,  if  the  change  rationale  and 
criticality  assessments  were  proper,  and  if  the  change's  effect 
on  their  programs  design/operations  were  properly  assessed. 

Each  screening  board,  via  its  SE&I  personnel,  would  perform  an 
initial  integration  task  to  insure  that  the  above  tasks  were 
accomplished  and  that  an  integrated  assessment  existed  across 
all  affected  programs/agencies. 

B.  The  screening  boards  would  determine  the  changes  category 
(i.e.  mandatory,  highly  desirable,  etc.),  its  effectivity  (e.g. 
one  or  more  orbiters),  and  would  perform  an  initial  determina- 
tion of  how  the  change  would  be  manifested  for  launch  or  by 
which  flight  it  would  be  implemented.  Again,  each  screening 
board's  SE&I  support  would  insure  that  an  integrated  assessment 
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existed  across  all  affected  programs/agencies.  In  addition, the 
screening  boards  manifesting  personnel  would  work  with  any  other 
SSP/NSTS  manifesting  experts  (e.g.,  a Tactical  Operations 
Control  Board)  to  properly  coordinate  manifesting. 

C.  Finally,  each  screening  board  would  provide  their  initial 
disposition  of  the  change.  The  dispositions  would  take  one  of 
two  forms:  (1)  Approval  for  further  full  assessment  of  the 

change  by  a change  assessment  team,  or  (2)  Disapproval  of  the 
change,  which  would  result  in  no  further  action  regarding  the 
change.  Any  disagreement  between  dispositions  of  any  of  the 
affected  screening  boards  would  result  in  a conflict  resolution 
appeal  to  the  Associate  Administrator  for  Operations.  Such  an 
appeal  route  would  also  be  available  to  the  CR  originator.  If 
all  of  the  screening  boards  approved  the  ESR  for  further  assess- 
ment, or  if  the  Associate  Administrator  for  Operations,  directed 
approval , then  the  ESR  would  be  forwarded  to  an  Assessment  Team 
for  each  affected  program/agency  and  Step  #3  of  the  process 
would  begin. 

Step  #3  - Assessment  - An  assessment  team  for  each  effected 
program/agency  would  perform  the  following  functions: 

A.  The  teams  would  develop  an  implementation  plan  and  schedule 
for  the  change. 

B.  The  teams  would  determine  the  Rough  Order  of  Magnitude  (ROM) 
costs  for  the  change  and  assess  the  required  contract  changes 
for  their  programs. 

C.  The  teams  would  initiate  and  complete  any  required  studies 
that  might  result  because  of  the  change. 

D.  The  teams  would  determine  any  other  impacts  resulting  from 
the  change  (e.g.,  weight  impacts,  launch  slip  impacts,  etc.). 

E.  The  teams  would  assess  the  interfaces  affected  by  the  change 
and  prepare  appropriate  ICD/IRD  changes. 

F.  Each  team,  via  its  SE&I  personnel,  would  coordinate  with 
each  other  to  insure  that  an  integrated  assessment  would  be 
achieved . 

6.  Upon  completing  an  integrated  assessment,  the  teams  would 
forward  the  assessment  in  the  form  of  an  Engineering  Analysis 
and  Cost  Assessment  (EACE),  or  equivalent,  to  a Joint  Change 
Evaluation  Board,  which  would  begin  Step  #4  of  the  process. 

Step  »4  - Joint  Change  Evaluation  Board  - A Joint  Change  Evalua- 
tion Board  would  receive  the  EACE  for  consideration.  This  board 
would  be  chaired  by  the  SSP  Program  Operations  Manager  and 
supported  by  similar  operations  managers  from  all  other  affected 
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programs /agencies,  each  with  an  equal  vote.  The  functions  of 
this  board  would  be: 

A.  The  Board  would  either  approve  or  disapprove  the  change.  If 
the  Board  disapproved  the  change,  no  further  action  on  the 
change  would  occur,  unless  a subsequent  appeal  to  the  Associate 
Administrator  for  Operations  reversed  the  decision.  Upon  Board' 
approval  of  the  change,  a joint  Change  Control  Board  Directive 
(CCBD)  would  be  issued  to  the  Design  and  Engineering  Organiza- 
tions of  the  affected  prograros/agencies,  and  Step  #5  would 
begin. 

B.  In  considering  the  change,  the  Board  might  also  issue 
further  actions  regarding  the  change  or  as  a result  of  the 
change.  The  Board  could  also  return  the  change  back  to  the 
respective  Assessment  Teams  for  further  reassessment. 

C.  The  Board  would  also  issue  Contract  Change  Authorizations 
(CCA's)  to  the  involved  contractors  of  each  affected  program/ 
agency,  and  would  notify  the  affected  manifesting/ logistics 
personnel  of  the  decision  so  that  proper  manifesting/ logistics 
planning  could  begin. 

Step  *5  - Design  and  Engineering  - Each  program/agency  Design 
and  Engineering  organization  would  receive  their  respective 
CCBD's,  and  begin  the  normal  activities  for  implementing  the 
change.  These  activities  would  include: 

a.  defining  the  detailed  design  requirements  and  specifica- 
tions, 

b.  preparing  drawings  and/or  implementation  instructions, 

c.  defining  detailed  verification  and  test  requirements, 

d.  supporting  the  preparation  of  test  procedures  and/or  analy- 
ses , 

e.  updating  various  affected  ICD ' s/IRD ' s/ACD' s/BCD' s 

f.  conducting  appropriate  design  and  safety  reviews,  and 

g.  performing  appropriate  assurance  analyses. 

Each  program' s /agency ' s SE&I  staff  would  be  responsible  for 
integrating  their  own  activities  and  coordinating  with  the  other 
affected  SE&I  staffs  in  order  to  assure  an  integrated  approach 
to  the  design  and  engineering  effort.  From  this  effort.  Docu- 
ment Release  Authorizations  (DRA's),  or  equivalent,  would  be 
released  to  each  program' s/ ' agency ' s manufacturing  personnel  to 
begin  Step  #6  of  the  process. 
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Step  t6  - Hardware /Software  Build  - Each  program' a /agency ' s 
manufacturing  team  would  begin  the  process  of  actually  building 
the  hardware/software  associated  with  the  change  modification. 
These  efforts  would  include: 

A.  support  for  the  procurement  of  the  piece  parts  and/or 
software  code  from  the  vendors  (subcontractors/contractors), 

I 

B.  the  support  required  for  the  actual  fabrication  of  each 
program* s /agency ' s hardware  portion  of  the  modification,  and  the 
support  required  for  the  building  of  software  programs  required 
by  any  program/agency, 

C.  the  processing  of  any  waivers /deviations  required  to  the 
original  design,  including  coordination  between  each  program/ 
agency  by  their  respective  SE&I  personnel , 

D.  the  processing  of  engineering  changes  to  the  original 
modification  design,  to  facilitate  the  manufacturing  process,  by 
each  affected  program/ agency , along  with  appropriate  integration 
of  these  changes  by  the  affected  SE&I  personnel , and 

E.  the  factory  verification  support  from  each  program/agency 
for  their  portion  of  the  modification,  including  development 
through  final  acceptance  verification  and  certification.  Such 
verification  would  also  include  an  integrated  certification  and 
acceptance  verification  for  the  end-to-end  system  affected  by 
the  modification  using  actual  flight  hardware /software  and/or 
simulators  as  required.  Such  verification  would  be  coordinated 
and  integrated  by  each  program' s /agency ' s SE&I  personnel. 

Once  this  step  is  complete,  each  program/agency  would  ship  their 
portion  of  the  mod-kit  to  the  launch  site,  where  the  final  phase 
of  this  scheme  would  begin  with  Step  #7 . 

Step  »7  - Change  Package  Support  - Each  program/agency  would 
have  engineering  and  management  support  personnel  located  at  the 
launch  site  to  help  perform  this  step,  which  would  include  the 
following  functions:  (NOTE:  The  actual  hands-on  work  at  the 

launch  site  would  be  performed  in  accordance  with  established 
methods  of  operating . ) 

A.  the  shipping,  receiving  and  quality  assurance  (QA)  inspec- 
tion for  each  program' s /agency ' s portion  of  the  mod-kit, 

B.  the  final  assembly  and  staging  for  each  portion  of  the 
mod-kit  along  with  stand-alone  power-on-testing  that  would  be 
required,  and 

C.  the  preparation  of  any  final  engineering  documentation 
associated  with  any  portion  of  the  mod-kit  required  for  final 
installation  and  integrated  testing. 
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Once  this  step  is  complete,  the  mod-kit  portions  would  be  turned 
over  to  the  SSP  launch  site  personnel  for  the  beginning  of  Step 
*8. 

Step  #8  - Verification  - SSP  launch  site  personnel  would  receive 
each  program' s /agency ' s portion  of  the  mod-kit  and,  off-line 
from  the  NSTS  processing,  integrate  the  mod-kit  into  a total  on- 
orbit  configuration  using  actual  flight  hardware  and  appropriate 
simulators.  This  would  be  done  to  accomplish  both  single  and 
multiple  launch  package  integration  and  verification  to  assure 
that  the  mod-kit  will  operate  as  designed  with  station/orbiter 
hardware/ software  that  is  already  on-orbit.  In  addition,  such 
verification  could  augment  crew  training  and  be  used  to  verify 
on-orbit  flight  procedures.  Once  this  step  is  complete.  Space 
Station  personnel  could  begin  Step  #9  of  the  process. 

Step  >9  - Transportation  Support  - Space  Station  personnel  would 
prepare  a configuration  definition  and  mass  property  analysis 
for  installing  various  portions  of  the  mod-kit  in  the  Orbiter 
Aft  Flight  Deck,  Orbiter  Payload  Bay,  and/or  the  SSP  Logistics 
elements.  Close  coordination  between  the  SSP  and  NSTS  SE&I, 
Logistics,  and  Ground/ Flight  Operations  personnel  would  be 
required  to  assure  that  orbiter  mods  were  properly  scheduled, 
logistics  elements  were  properly  manifested,  that  the  Orbiter 
Payload  Bay  and/or  Aft  Flight  Deck  was  properly  manifested,  and 
that  on-orbit  station  installation  and  checkout  operations  were 
properly  scheduled.  Once  these  function  were  completed.  Step 
#10  of  the  process  would  begin. 

Step  #10  - Installation  and  Checkout  - Each  affected  program/ 
agency  would  begin  the  task  of  supporting  and/or  installing/ 
manifesting,  as  appropriate,  portions  of  the  mod-kit  into  their 
affected  hardware /software  subsystems /systems.  Actual  hands-on 
work  would  be  accomplished  by  established  methods  of  operating, 
installations  would  be  followed  by  appropriate  support  for  final 
verification  and  checkout  of  the  affected  subsystems / systems . 
This  installation/checkout  could  occur  on  the  ground  and/or 
on-orbit,  and  would  be  followed  by  an  analysis  of  predicted  data 
and  the  processing  of  any  final  waivers /deviations  by  each 
affected  program/agency . At  the  completion  of  this  task, 
"installation  complete  (INC)"  notices  would  be  given  to  each 
affected  program' s /agency ' s configuration  management  and  verifi- 
cation personnel  teams  to  begin  Step  #llf  the  process. 

Step  #11  Configuration  Update  - Each  program' s /agency ' s configu- 
ration management  and  verification  personnel  teams  would  accom- 
plish the  final  step  of  this  process,  which  would  include: 

A.  updating  all  drawings  and  documentation  to  the  as-build 
configuration , 

B.  providing  CCBD  closeout  documentation. 
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C.  completing  verification  completion  notices,  or  equivalent, 
(VCN's)  and  updating  the  appropriate  verification  data  bases, 

D.  performing  any  other  required  configuration  accounting 
actions  required  by  each  affected  prog ram/ agency . 

The  completion  of  the  step  would  complete  the  entire  change 
management  and  sustaining  engineering  effort  for  such  a change. 

SOMMARY 

This  paper  has  attempted  to  deal  with  one  aspect  of  the  sustain 
ing  engineering  effort  required  for  the  SSP  and  other  interre- 
lated programs  during  the  SSP  operational  era  - the  "Change 
Management /Implementation  Process".  The  proposed  change  manage 
ment  scheme  is  but  one  way  that  such  a scheme  could  evolve,  but 
it  is  felt  that  such  an  evolution,  or  a similar  one,  will  be 
necessary  if  the  SSP  is  to  cope  with  the  operational  complexi- 
ties that  will  exist  during  this  era. 
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5.0  TRANSPORTATION  SERVICES/RESCUE 
5.1  INTRODUCTION 

After  the  Space  Station  Program  (SSP)  becomes  operational,  the 
transportation  and  services  aspect  of  the  SSP  will  be  one  of 
the  most  costly  and  labor  intensive  portions  of  the  Space 
Station  support  systems.  The  methods  utilized  by  the 
transportation  and  services  operations  associated  with  the  SSP 
will  have  to  be  considerably  different  than  those  implemented 
for  the  SSP  Design,  Development,  Test,  and  Evaluation  (DDT&E) 
phase.  Required  management  and  operational  response  time, 
efficiency,  and  cost  effectiveness  will  dictate  that  an 
evolution  in  operational  and  management  techniques  take  place 
in  order  to  be  user  friendly  yet  managerial ly  effective  during 
the  operational  phase. 

During  the  DDT&E  phase,  the  National  Space  Transportation 
System  (NSTS)  will  be  devoted  almost  exclusively  to  the 
establishment  of  the  major  architecture  of  the  Space  Station. 
Once  the  Space  Station  is  constructed,  manned,  and  declared 
operational,  the  operation  of  a Space  Station  Program  during 
the  next  twenty  years  will  require  utilizing  the  resources  of 
the  entire  repertoire  of  Space  Transportation  systems  both  in 
the  United  States  as  well  as  those  of  the  International 
Partners  in  order  to  have  a cost  effective,  viable  program. 

This  section  describes  the  capabilities  and  options  that  may  be 
available  for  transportation  services  and  rescue  during  the  SSP 
time  frame. 
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5.1.1  Transportation  Services /Rescue 


The  transportation  systems  to  support  the  Space  Station 
subsequent  to  2000  will  require  a robust  fleet  of  space 
vehicles.  The  findings  and  recommendations  of  the  NASA  mixed 
fleet  study  team  released  on  January  12,  1987,  (Branscome, 
special  programs),  stated  that  a mixed  fleet  is  required  to 
support  the  Space  Station  because  the  NASA  launch  capability  is 
not  robust  even  with  a high  expendable  launch  vehicle  option. 


Ground  Rules  and  Assumptions 

o The  Space  Shuttle  (STS)  and/or  its  replacement  (Shuttle 
II)  is  operational 

o The  Space  Station  is  fully  operational 

o Maximum  Space  Station  crew  size  is  18  members 

o Crew  Rescue  Vehicles  have  a capacity  for  up  to  6 
members  each 

o There  will  be  sufficient  crew  rescue  capability  for  all 
station  members  at  all  times 

o Space  Station  support  is  provided  by  domestic  space 
transportation  systems  and  could  be  supplemented  with 
foreign  space  vehicles  as  necessary 

o A minimum  of  one  orbital  maneuvering  vehicle  (OMV)  will 
be  based  at  the  Space  Station 

o The  propulsion  unit  of  the  OMV  will  be  serviced 

routinely  at  a ground  based  facility  (and  therefore 
routinely  require  transport  to  the  ground  and  back  to 
the  station) 

o The  cold  gas  system  of  the  OMV  short  range  vehicle  will 
be  serviced  at  the  station 

o The  possibility  of  returning  an  unpressurized  Logistics 
module  using  a non-Station  Shuttle  mission  exists 
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Existing  Shuttle  System  Vehicle  Overview 


The  Space  Shuttle  consists  of  a reusable  delta-wing  spaceplane 
called  the  orbiter  with  two  solid-propellant  rocket  boosters, 
which  are  recovered  and  also  reused,  and  an  expendable  external 
tank  containing  cryogenic  propellants  for  the  orbiter' s main 
engines.  The  tank  contains  separate  compartments  for  liquid 
hydrogen  and  liquid  oxygen. 

At  launch,  the  orbiter' s three  liquid-fueled  rockets  and  the 
solid  rockets  generate  7 million  pounds  of  maximum  thrust.  As 
the  Space  Shuttle  reaches  an  altitude  of  about  31  miles,  the 
spent  solid  rockets  are  detached  and  parachute  into  the  ocean 
for  recovery  and  reuse.  The  orbiter  and  tank  continue  toward 
low  Earth  orbit.  When  the  orbiter' s main  engines  cut  off,  the 
external  tank  is  jettisoned  to  impact  in  a remote  ocean  area. 
The  orbiter  with  its  crew  and  payload  accelerates  into  orbit  to 
carry  out  an  operational  mission.  When  the  mission  has  been 
completed,  the  orbiter  re-enters  the  atmosphere  and  returns  to 
Earth.  Touchdown  speed  is  above  210  miles  per  hour. 

The  assembled  Shuttle  vehicle  is  approximately  184  feet  long 
and  76  feet  high.  The  orbiter  measures  about  122  feet  long  and 
has  a wingspan  of  around  78  feet.  Its  payload  bay  is  60  feet 
long  and  15  feet  wide. 

The  capability  of  the  Space  Shuttle  has  been  revised  after  the 
51-L  accident  and  is  shown  below. 

Orbital  Capabilities: 

Op  weight  - 39,500  lbs. 

Down  weight  - 21,500  lbs 
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Shuttle  Growth  Vehicles 


Because  of  the  decreasing  launch  weight  capability  of  the  STS 
with  current  solid  rocket  boosters  (SRB),  improvements  in 
performance  is  desired.  While  this  can  be  accomplished  with 
improved,  next  generation  solid  rocket  boosters,  another 
effective  way  to  accomplish  this  is  to  replace  the  SRBs  with 
liquid  rocket  boosters  (LRBs).  Some  of  the  potential 
advantages  of  LRBs  compared  to  SRBs  include  thrust  termination 
capability  and  performance  flexibility  such  as  increased 
payload  capability,  throttling,  thrust  tailoring,  and  engine 
out  capability.  LRBs  potentially  offer  higher  reliability  and 
improved  ground  processing  including  safer  handling  and 
potentially  faster  turnaround.  They  also  offer  more  acceptable 
environmental  conditions  (i.e.,  no  acid  rain)  and  may  lend 
themselves  more  readily  to  design  modifications,  inspection, 
and  testing. 

Candidate  LRB  replacements  are  shown  in  Figure  5-1.  Each  of 
these  offer  significant  performance  improvements  over  the 
existing  system,  and  generally  have  Low  Earth  Orbit  delivery 
capabilities  of  about  100,000  pounds. 

Use  of  existing  F-l  engine  designs  from  the  Saturn  V program, 
with  some  modifications,  is  one  LRB  option.  This  approach 
would  require  about  a 5 year  development  program,  but  has  a 
high  potential  payload  growth  capability  with  low  DDT&E  re- 
quired. As  envisioned,  each  LRB  would  have  two  engines,  stand 
about  150  feet  high,  and  is  just  over  15  feet  in  diameter. 
Another  option  is  the  SSME35  LRB  with  4 engines  each.  This 
low  DDT&E,  low  development  risk  program  would  require  about  a 5 
year  development  program,  and  has  a wide  range  of  applications. 
This  booster  is  also  about  150  feet  high,  but  about  20  feet  in 
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Figure 


diameter.  Another  option  is  the  5-engine  pressure-fed  booster. 
It  is  about  160  feet  high,  19  feet  in  diameter,  and  has  a 6-9 
year  development  requirement  with  relatively  high  DOT&E. 

Because  of  the  high  pressure,  the  thick  tank  walls  make  it 
amenable  to  water  recovery.  Another  option  is  the  hybrid 
booster,  which  has  solid  fuel  and  liquid  oxidizer.  Since  it  is 
an  unproven  concept,  the  feasibility  has  not  been  verified  and 
a 10-year  development  time  is  forecast. 

While  additional  payload  capability,  if  needed,  could  be 
attained  with  improved  solids  or  new  LRBs,  integration  of  LRBs 
into  the  STS  configuration  and  launch  facilities  is  a major 
consideration.  The  impact  is  probably  largest  with  the  pres- 
sure fed  boosters  because  of  the  increased  diameter  required. 
Studies  and  experiments  are  needed  to  confirm  viable  means  for 
water  recovery  and  reuse  of  pump-fed  propulsion  systems,  and 
the  utility  of  on-pad  or  ascent  shutdown  capability  needs  to  be' 
better  understood.  System  studies  and  supporting  technology 
efforts  can  provide  a better  basis  for  decisions  and  selection 
of  approach.  Use  of  LRBs  for  the  Shuttle  might  best  be 
preceded  by  verification  with  Shuttle  Derived  Vehicles  (SDVs) 
because  of  safety  considerations. 

Shuttle  II 

Subsequent  to  2000,  the  current  STS  will  need  replacing  because 
of  system  lifetime  and  the  need  for  a newer,  higher  technology, 
and  more  efficient  vehicle.  There  are  now  many  concepts  for 
this  "Shuttle  II"  including  Single  Stage  to  Orbit  (SSTO)  with 
the  SRBs , two-stage,  and  Advanced  SSTO.  Examples  of  these 
concepts  are  shown  in  Figure  5-2.  All  concepts  have  delivery 
capabilities  comparable  to  the  present  Shuttle  system,  or  about 
40,000  pounds  to  the  Space  Station  orbit.  Desires  for  this 
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SHUTTLE  II  CONCEPTS  COMPARED 
TO  SPACE  SHUTTLE 
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COMPARED  TO  SHUTTLE  TECHNOLOGY 


next  generation  Space  Shuttle  include  low  cost  per  flight, 
total  reusability,  all-weather  capability  (within  reason), 
robust  surfaces,  large  performance  margins,  small  ground  crew 
requirements,  quick  turnaround,  minimal  payload  handling,  and 
amenability  to  non-NASA  operations.  Some  higher  technology 
developments  include  advanced  materials  and  structures,  durable 
TPS  and  hot  structures,  and  cooled  materials.  Other  design 
features  may  include  a detachable  payload  canister  and  axially 
separable  internal  tanks.  Advanced  performance  technologies 
for  weight  reduction  may  include  lightweight  structures 
(carbon-carbon,  new  metal  matrix  materials),  high  performance, 
light  weight  rocket  engines  (using  composite  materials  and  high 
performance  pumps,  bearing,  and  preburners),  lightweight 
subsystems  (using  advanced  avionics,  fiber  optics,  AI,  and 
expert  systems),  and  advanced  configurations  and  control  (such 
as  adaptive  GN&C  and  fault  tolerant  electronics).  A possible 
evolutionary  path  for  Shuttle  II  development  from  expendable 
SDVs,  recoverable  SDVs,  and  reusable  winged  boosters. 

Domestic  Cargo  Vehicles  - Expendable  Vehicles. 

Titan  IV  - The  Air  Force  has  been  authorized  to  proceed  with 
the  development  and  procurement  of  23  new  Titan  4 launch  vehi- 
cles to  meet  their  requirements  for  assured  access  to  space. 
(See  Figure  5-3.)  The  first  launch  of  the  IDS  upperstage 
version  is  1989,  with  the  Centaur  version  beginning  in  1990. 

The  Titan  4,  or  Titan  34D7,  is  the  latest  addition  to  the 
family  of  Titan  launch  vehicles.  The  Titan  III  has  successful- 
ly completed  129  operational  launches  since  1967  for  a 97 
percent  success  rate.  The  Titan  4 is  an  improved  version  of 
the  Titan  34D  space  launch  system,  with  stretched  first  and 
second  stages,  seven-segment  solid  rocket  motors,  a 16.7-foot 
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diameter  payload  fairing,  and  a Centaur  G-prime  or  IUS  upper 
stage.  Overall  length  of  the  system  is  204  feet.  The  key load 
capability  to  220  n.m.  at  28.50  is  approximately  20,000  lbs. 

Delta  Vehicles  - The  Delta  is  called  the  workhorse  of  the  space 
program.  This  vehicle  has  successfully  transported  over  150 
scientific,  weather,  communications,  and  applications 
satellites  into  space.  Also,*  the  Delta  launch  vehicle  has  been 
selected  as  the  Medium  Launch  Vehicle  (MLV)  for  the  Air  Force 
deploying  the  Global  Positioning  Satellite  system. 

First  launched  in  May  1960,  the  Delta  has  been  continuously 
upgraded  over  the  years.  Today  it  stands  116  feet  tall.  Its 
first  stage  is  augmented  by  nine  Caster  IV  strap-on  solid 
propellant  motors,  six  of  which  ignite  at  liftoff  and  three 
after,  the  first  six  burn  out.  The  average  first-stage  thrust 
with  the  main  engines  and'  six  solid  propellant  motors  burning 
is  718,000  pounds.  Delta  has  liquid-fueled  first  and  second 
stages  and  a solid-propellant  third  stage. 

The  configuration  of  the  Delta  rocket  for  the  MLV  program  will 
be  an  upgrade  from  the  present  vehicle.  The  vehicle  will  be 
lengthened  and  high  performance  solid  propellant  will  be  used. 
The  capability  of  the  Delta  rocket  to  low  Barth  orbit  will  be 
TBD  with  an  eight  foot  diameter  payload  fairing. 

At las /Centaur  Vehicles  - The  Atlas/Centaur  is  NASA's  standard 
launch  vehicle  for  intermediate  payloads.  It  is  used  for  the 
launch  of  Earth  orbital,  geosynchronous,  and  interplanetary 
missions. 
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Centaur  was  the  nation's  first  high  energy,  liquid-hydrogen, 
liquid-oxygen  propelled  launch  vehicle  stage.  Since  1966,  both 
the  Atlas  booster  and  the  Centaur  second  stage  have  undergone 
many  improvements.  At  present,  the  combined  stages  can  place 
12,000  pounds  in  low  Earth  orbit. 

An  Atlas/Centaur  stands  approximately  131  feet  tall.  At 
liftoff,  the  Atlas  booster  develops  over  431,000  pounds  of 
thrust.  The  Centaur  second  stage  develops  30,000  pounds  of 
thrust  in  vacuum. 

Shuttle  Derived  Vehicles  - Shuttle  Derived  Vehicles  (SDVs)  are 
launch  vehicles  that  utilize  existing  components  from  the  Space 
Shuttle  but  have  a payload  compartment  instead  of  an  Orbiter. 
While  these  components  are  sometimes  necessarily  modified 
because  of  different  load  paths,  they  are  essentially  the  same 
proven  systems.  SDVs  have  been  studied  in  some  form  since  the* 
mid-1970s,  both  by  in-house  NASA  and  contracted  studies. 
Concepts  include  both  expendable  and  reusable  main  engine 
versions,  the  latter  using  a Propulsion/ Avionics  Module,  and  if 
development  started  now,  could  be  ready  for  launch  in  the  early 
1990s.  Early  versions  of  SDVs  generally  include  the  same  solid 
rocket  boosters  as  the  present  Shuttle  system,  but  if  liquid 
boosters  are  used  for  Shuttle  performance  enhancement,  these 
can  easily  be  adapted  to  the  SDVs.  Liquids  generally  offer 
benefits  over  solids  for  performance,  flexibility,  operational 
simplicity,  and  environmental  impact. 

SDVs,  because  they  do  not  carry  the  Orbiter,  have  more  payload 
capability  than  the  Shuttle.  Depending  upon  the  configuration, 
payload  capacities  generally  range  from  75,000  to  200,000 
pounds  to  Low  Earth  Orbit. 
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One  of  the  main  advantages  of  SOVs  is  that  many  factors  are 
common  with  the  STS.  If  the  15'  x 60*  payload  size  is  main- 
tained, many  facilities  such  as  assembly  buildings, 
transporters,  launch  pads,  and  test  and  verification  sites  can 
be  shared.  Tanks,  integration  hardware,  and  transportation 
modes  are  the  same.  Many  major  hardware  elements  such  as 
engines,  thrust  structure,  nozzles,  and  payload  fairings  are 
the  same  as  well  as  others  such  as  avionics  systems  and 
cryolines,  valves,  and  insulation.  The  operations  processes  of 
assembly,  transportation,  launch  and  orbital  sequences  are  the 
same  or  similar. 

Two  basic  SDV  configurations,  the  side  mount  and  the  in-line, 
are  most  often  considered.  Each  of  these  has  variations  that 
lead  to  a family  of  vehicles  covering  a wide  performance  range. 
Figure  5-4  shows  the  evolutionary  flow  from  the  STS  to  both 
types  of  SDVs,  with  further  development  to  a reusable  main 
propulsion  system. 

Studies  are  currently  underway  to  investigate  the  feasibility 
of  P/A  Module,  where  main  propulsion  and  avionics  systems  are 
packaged  together  in  a reusable  pod,  for  use  in  SDV  and 
possibly  other  launch  systems.  The  development  of  advanced 
precision  recovery  systems  for  high  cost  components,  such  as 
the  P/A  Module,  is  being  considered  to  reduce  launch  costs 
considerably.  Such  systems  would  allow  minimal  touchdown 
damage  and  decrease  refurbishment  and  integration  times, 
particularly  if  the  system  can  accommodate  land  touchdown  and 
avoid  the  salt  water  corrosion  problems  associated  with  ocean 
splashdown. 

Side  Mount  - The  side  mount  SDV  is  identical  to  the  STS,  except 
the  Orbiter  is  replaced  with  a "side  mounted"  payload  carrier. 
The  payload  size  may  range  from  15'  x 60'  (STS  size)  to 
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25'  x 90'.  If  the  STS  size  payload  is  maintained,  few  Kennedy 
Space  Center  facility  modifications  are  required.  Since  OPF 
activities  are  no  longer  needed,  the  flow  is  actually 
simplified.  Payloads  would  be  integrated  vertically  on  the  pad 
as  most  are  now,  with  no  modifications  needed  to  the  RSS  or 
MLP.  A larger  payload  would  require  new  or  modified  payload 
processing  facilities,  as  well  as  off-line  payload  integration 
or  changes  to  launch  pad  RSS  and  POR. 

The  Side  mount  SDV,  users  STS  SRBs,  ET,  and  SSMEs  unchanged. 

In  the  reusable  version,  engines  and  avionics  are  combined  into 
a Propulsion/ Avionics  (P/A)  Module  which  is  recovered  and 
refurbished  for  further  use.  If  a 25'  diameter  shroud  is  used, 
special  15*  foot  cradles  can  be  developed  to  adapt  for  STS 
payloads . 

Performance  from  ETR  to  a 28.5  degree  Low  Earth  Orbit  ranges 
from  about  100,000  lbs  for  a two-engine  reusable  version  to 
over  150,000  for  the  three-engine  expendable  version. 

The  major  advantage  of  the  side  mount  over  the  in-line  version 
is  that  it  requires  a minimum  change  to  the  present  STS  facili- 
ties. Once  the  payload  carrier  is  developed,  it  could  enter 
the  processing  flow  with  a minimum  impact.  Compared  to  the 
in-line  configuration,  performance  is  slightly  lower  because  of 
the  off-center  thrust  of  the  main  engines  and  the  asymmetric 
aerodynamic  shape. 

Inline  SDV  - The  Inline  SDV  configuration  has  the  payload 
carrier  mounted  on  top  of  ("in-line"  with)  the  External  Tank, 
with  the  main  propulsion  engines  under  the  tank.  Standard  SRBs 
are  attached  to  the  ET  in  the  usual  manner.  The  ET  is  modified 
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somewhat.  The  hydrogen  tank  and  intertank  structure  are 
unchanged,  but  the  LOX  tank  aft  ring  is  inverted  and  the  LH2 
tank  forward  dome  is  used  on  the  forward  end  of  the  LOX  tank. 
This  is  necessary  to  support  the  payload  atop  the  ET.  On  the 
aft  end  of  the  ET.  the  insulation  for  aerodynamic  heating  is  no 
longer  necessary,  but  new  thrust  structure  for  the  main  engines 
is  required.  The  payload  shroud  is  new  hardware,  and  is 
jettisoned  inflight  after  maximum  dynamic  pressure.  As  with 
the  side  mount  configuration,  payloads  can  range  from  15'  x 60* 
to  25 ' x 90 ' . Payload  adapters  can  be  used  for  STS-sized 
payloads  in  the  larger  diameter  version.  Because  of  the 
cleaner  aerodynamic  shape  and  the  on-center  thrust,  weight 
placement  capability  is  higher  than  the  side  mount  with  the 
same  number  of  engines. 

Performance  ranges  form  about  80,000  pounds  in  the  single 
engine  expendable  version  to  over  200,000  pounds  for  the  three 
engine  expendable.  Reusable  engine  versions  (with  a P/A 
Module)  range  from  about  140,000  pounds  to  180,000  pounds  for 
two  and  three  main  engines,  respectively.  A performance 
summary  comparing  both  side  mount  and  inline  SDVs  is  shown  in 
Figure  5-4. 

Launch  site  facility  modifications  are  somewhat  more  extensive 
than  with  the  side  mount.  Payload  integration  will  be  done 
away  from  the  pad  (possibly  in  the  VAB) , and  payload  access  at 
the  pad  is  not  possible  without  special  equipment.  Because  of 
the  payload  height  and  location,  modifications  to  the  payload 
umbilical s is  necessary,  as  well  as  service  tower  and  lightning 
mast  extension.  The  MLPs  are  not  presently  configured  with  a 
flame  exit  hole  at  the  main  engine  location,  so  a modification 
is  necessary  here  or  else  suffer  a performance  loss  with  an 
altitude  start  of  the  SSMEs. 
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Heavy  Lift  Launch  Vehicles  - A large  Heavy  Lift  Launch  Vehicle 
( HLLV ) designed  to  deliver  300  - 400,000  pounds  to  Low  Earth 
Orbit  may  be  required  to  meet  national  needs  for  1995  and 
beyond,  and  may  have  applications  in  the  operational  era  of  the 
Space  Station.  The  vehicle,  shown  in  Figure  5-5,  can 
accommodate  payload  envelopes  up  to  50  feet  in  diameter  by  200 
feet  in  length.  Payloads  utilizing  this  capability  may  be 
Space  Station  elements  (particularly  in  the  growth 
configuration),  commercial  space  facilities,  or  advanced 
military  systems. 

Design  requirements  of  this  vehicle  include  reusability  of  the 
more  expensive  components  such  as  avionics  and  propulsion 
systems,  rapid  launch  turnaround  time,  minimum  hardware  inven- 
tory, stage  and  component  flexibility  and  commonality,  and  low 
operational  costs.  All  ascent  propulsion  systems  utilize 
liquid  propellants  and  overall  launch  vehicle  stack  height  is 
minimized  while  maintaining  a reasonable  vehicle  diameter. 

This  configuration  is  a parallel  burn  two-stage  vehicle  which 
used  LOX/JP4  boosters  consisting  of  four  tank  sets  or 
substages,  two  246-inch  diameter  and  two  171-inch  diameter. 

The  larger  sub-stages  have  two  1/6  million  pounds  thrust 
advanced  main  engines  and  the  smaller  substages  have  one  engine 
each,  for  a total  of  six  booster  engines.  The  second  stage  is 
396  inches  in  diameter  and  has  five  two-position  nozzle 
engines.  All  first  and  second  stage  engines  are  ground  ignited 
and  flown  in  parallel  burn  until  booster  staging. 

Cargo  Return  Vehicles  - All  of  the  launch  vehicles,  except  for 
the  Shuttle  system,  has  only  the  capability  to  launch  payloads 
to  orbit.  The  need  to  return  payloads  back  to  Earth  from  the 
Space  Station  is  a major  requirement.  The  current  Space 
Shuttle  system  has  a mismatch  of  about  15,500  pounds  in  its 
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Figure 


ability  to  return  payloads  versus  launch  them  to  orbit.  The 
use  of  the  Shuttle  alone  will  cause  a backlog  of  payloads  to  be 
returned  to  Earth.  The  driving  factor  for  the  productivity  of 
the  Space  Station  will  become  the  down  weight  capability  of  the 
transportation  system.  Concepts  need  additional  development 
and  emphasis  for  the  Space  Station  program  to  enable  use  of  an 
efficient  transportation  system. 

The  Cargo  Return  Vehicle  concept  is  based  on  the  CERV  design 
but  without  the  manned  features.  The  vehicle  would  be  reusable 
with  low  refurbishment  costs.  The  vehicle  will  be  able  to  meet 
time  critical  payload  requirements  which  will  be  a key  factor 
to  the  user  community.  A proposed  design  is  shown  in 
Figure  5-6. 

Foreign  Space  Transportation  Systems  - In  spite  of  the 
operation  of  the  reusable  U.  S.  Space  Shuttle,  the  era  of 
conventional  expendable  launch  vehicles  is  not  over  and  a new 
generation  of  classic  launch  vehicles,  Japan's  H-ll  rocket  and 
Europe's  Ariane  5,  is  being  developed.  The  foreign  launch 
vehicle  programs  have  also  started  towards  development  of 
reusable  orbiter  type  vehicles  for  manned  space  operations. 

Figures  5-7  and  5-8  shows  future  foreign  development  launch 
vehicles. 

European  Space  Agency  (ESA) 

Overview.  The  European  Space  Agency's  eleven  member-states  met 
in  early  1985  to  define  their  objectives  for  the  next  decade. 

They  settled  on  three:  an  autonomous  capacity  to  work  in  space; 
the  construction  of  a small,  reusable  shuttle;  and  the  development 
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of  a large  Ariane  5 rocket  that  is  an  integral  component  of  the 
shuttle  package. 

The  small  shuttle,  dubbed  Hermes,  is  being  developed  in  France 
with  the  backing  of  the  eleven-nation  European  Space  Agency. 

The  orbiter  will  be  launched  by  the  expendable  Ariane  5 rocket, 
currently  in  its  development  stage.  Hermes  will  carry  four  or 
more  astronauts  and  a 10,000  pound  payload  into  orbit,  then 
return  for  a runway  landing  on  Earth.  Current  plans  call  for 
two  spaceplanes  to  be  built,  and  for  the  first  flight  to  take 
place  in  1995  on  only  the  third  Ariane  5 launch. 

Hermes  will  be  used  for  independent  flights  of  various  types 
and  servicing  missions  to  satellites  and  free-flying  platforms. 
But  its  most  important  role  will  be  to  ferry  people  and  equip- 
ment to  and  from  space  stations. 

The  goals  for  the  development  of  the  Ariane  5 launch  vehicle 
includes  a substantial  increase  over  Ariane  4 in  payload  lift 
capability,  along  with  an  increase  in  payload  diameter  to  match 
that  of  the  Space  Shuttle.  The  new  launch  vehicle  is  designed 
with  a reliability  goal  compatible  with  manned  flights  for  the 
Hermes  manned  spacecraft.  The  first  Ariane  5 test  flight  is 
scheduled  for  late  1994,  from  a new  launch  site  at  Kourou.  The 
first  operational  flight  is  scheduled  for  1995. 

The  Hermes  concept  is  based  on  the  principle  that  automatic 
payloads  are  launched  more  economically  and  more  safely  by 
automatic  vehicles  than  by  manned  launchers,  and  that  manned 
transportation  vehicles  should  be  used  only  when  man's  presence 
is  definitely  required  by  the  mission.  It  leads  to  the  Ariane 
5 /Hermes  concept,  in  which  the  same  basic  core  launcher  can  be 
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topped  with  different  upper  stages  and  fairings  for  automatic 
missions,  or  with  Hermes  for  manned  missions. 

The  delta  wing  Hermes  spacecraft,  shown  in  Figure  5-9,  is  about 
half  the  size  of  the  Space  Shuttle  with  the  size  of  the  cargo 
bay  considerably  smaller  than  that  of  the  Space  Shuttle,  due  to 
the  fact  that  it  is  not  designed  to  carry  satellites.  Hermes, 
being  a spacecraft  and  not  a launcher,  does  not  carry  the 
launch  propulsion  system,  but  only  a low  thrust  propulsion  unit 
for  orbit  maneuvers  and  deorbiting 

In  its  initial  design,  Hermes  is  58.7  feet  long,  and  it  stands 
16  feet  high.  Four  people  would  be  comfortable  in  its  crew 
compartment;  six  would  be  cramped.  The  stubby  vehicle  has 
sharply  upswept  rudders  at  the  tips  of  its  delta  wings.  Upper 
and  lower  elevons  extend  from  the  wings  trailing  edges  and  a 
single  body  flap  will  be  mounted  beneath  the  rear  fuselage. 
Table  5-1  summarizes  the  main  features  of  the  Hermes  space- 
craft. 

The  Ariane  5 is  being  developed  as  a three-spage  expendable 
launch  vehicle  with  lower  composite  comprising  of  two 
solid-rocket  boosters  and  cryogenic  liquid-propellant  main 
stage.  The  upper  composite  comprising  either  a low-energy 
storable  liquid-propellant  L4  stage,  a high-energy  cryogenic 
liquid-propellant  H10  stage,  or  the  Hermes  spacecraft. 

The  Ariane  5 will  use  two  boosters  for  lift-off  and  initial 
ascent  each  consisting  of  170  tons  of  HTPB  solid  propellant 
each  producing  450  tons  of  thrust.  The  main  stage  will  burn 
120  tons  of  cryogenic  propellant  (LOX/LH2>  with  one  Vulcain 
cryogenic  engine  producing  102  tons  of  thrust.  The  payload 
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Hermes  specifications 


Length 

16  m 

Height 

6 m 

Wingspan 

10  m 

Cargo  bay 

3 m (diameter) 

3 m (length) 

33  cu  m (volume) 

Cargo 

4300  kg  (in  equatorial 

capacity 

orbit) 

Crew 

4-6 

Weight 

9 tons  (empty) 

Launcher 

Ariane  3 

Power 

Fuel  ceils  or  lithium 
batteries.  Propellant  driven 
turbines.  Solar  arrays  (long 
duration  only) 

PropnMoa 

Three  engine  subsystems 
using  2300  kg  of  propellant 
(MMH,  N204) 

• Attitude  control  system 

• Orbital  manoeuvring  and 
rendezvous  system 

• Orbital  Insertion  deorbit 
and  abort  system 

Orbital 

400  km  (circular  low* 

parameters 

altitude  orbit  with  a 0*-60* 
inclination) 

300-800  km 

(sunsyochronous  orbits 
with  reduced  payload 
capacity  (1300-2300  kg)  and 
reduced  crew  (2-4)) 

Mission 

7-28  days  (depending  on 

duration 

number  of  crew) 

90  days  (long  duration 
missions  possible  when 
docked  with  space  station) 

Atmospheric 

10000  km  (longitudinal 

manoeuvring 

range) 

2300  km  (lateral 
crossrange) 

Launch  site 

Kourou  (French  Guiana) 

Landing  aha 

Kourou  (French  Guiana) 
I st res  (France) 

First  flight 

1995 

Coat 

2000  MAU  (million 
accounting  units  in  1983 
terms) 

Table  5-1 
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fairing  will  be  4.55  meters  in  diameter  with  the  Spelda-type 
multiple  launch  structure  developed  for  the  Ariane  program. 

The  Ariane  5 will  have  a one  or  two  stage  cryogenically  fueled 
core  and  two  solid-fuel  strap-on  boosters.  With  two  core 
stages,  Ariane  5 will  be  able  to  put  two  satellites,  together 
weighing  more  than  17,000  pounds,  into  geostationary  orbit. 

With  a single  core  stage,  it  could  carry  33,000  pounds  to  low 
Earth  orbit.  The  single  stage  version  would  loft  Hermes  into 
space . 

All  launches  will  come  from  the  French  facility  near  the 
equator  at  Kourou,  French  Guiana.  Hermes  will  also  land  at 
Kourou,  touching  down  on  a standard  11,500  foot  runway.  Like 
the  0.  S.  shuttle,  Hermes  will  return  to  Earth  as  an  unpowered 
glider. 

Japanese  Space  Vehicles 

The  National  Space  Development  Agency  of  Japan  ( NASDA ) has  made 
a major  effort  to  obtain  a heavy-lift  launch  vehicle  with  the 
initiation  in  1985  of  the  H-II  development  program.  The  H-II 
is  a new  expendable  launch  vehicle  to  meet  the  demand  for 
Japanese  space  activities  in  the  1990 's.  With  the  successful 
development  of  the  N rocket  family,  Japan  has  established  the 
technology  for  launching  satellites  into  Geostationary  Earth 
Orbit  (GEO).  The  H-II  rocket  is  being  designed  to  launch  a 
2 ton  satellite  into  GEO  with  a projected  lift  capability  to 
the  Space  Station  orbit  of  8500  pounds.  First  launch  of  the 
H-II  rocket  is  proposed  for  early  1992.  As  shown  in 
Figure  5-10  the  H-II  vehicle  is  compact  in  size  and  light  in 
weight  compared  with  similar  launch  vehicles  throughout  the 
world. 
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NASDA's  goals  for  the  H-II  program  include  minimizing  cost  for 
payload  delivery  and  maximizing  reliability,  even  in  the  early 
phase  of  the  new  launch  vehicle.  An  independent,  reliable, 
economical,  and  user  friendly  launch  vehicle,  the  H-II  rocket, 
will  become  available  in  1992  and  it  may  result  in  competitive 
capability  in  the  field  of  commercial  launch  services. 

The  H-II  rocket  consists  of  cryogenic  first  and  second  stages 
at  4 meters  in  diameter  and  a pair  of  strap-on  solid  rocket 
boosters.  It  is  255  tons  in  lift-off  mass  and  48  meters  in 
height.  The  first  stage  loads  85  tons  of  LOX/LH  propellants 
and  is  powered  by  a single  LE7  engine  delivering  120  tons 
thrust  in  vacuum  at  a specific  impulse  of  449  seconds. 

Figure  5-11  and  show  a general  view  and  principal  specifica- 
tions of  the  H-II  rocket,  respectively.  These  figures  are 
based  on  Phase  B results.  The  H-II  rocket  employs  conservative 
design  for  high  reliability  and  low  cost. 

The  standard  payload  fairing  is  4 meters  in  diameter,  matching 
the  main  body  diameter,  and  12  meters  long.  However,  it  is 
possible  to  increase  the  diameter  of  the  payload  fairing  to 
5 meters  which  is  compatible  with  the  Space  Shuttle  cargo  bay 
and  the  Ariane  5 payload  fairing. 

The  flight  sequence  of  a standard  GEO  mission  is  shown  schemat- 
ically in  Figure  5-12.  The  LE-7  engine  is  ignited,  upon  thrust 
build  up  of  the  engine,  two  SRB's  are  ignited  and  the  H-II  is 
released  from  the  pad.  The  SRB's  and  main  engine  provide  the 
thrust  for  the  first  portion  of  the  flight.  The  SRB's  burn  out 
at  95  seconds  after  lift-off  and  seconds  later  they  are  sepa- 
rated from  the  core  vehicle.  The  main  engine  continues  to  burn 
for  a total  duration  of  315  seconds.  The  maximum  acceleration 
of  3.6  g's  at  the  first  stage  burnout  is  low  enough  to  protect 
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Typical  Flight  Sequence  ( GTO  Launch  Mission  ) 

Figur^S-12 


sensitive  payload  structures.  The  H-II  will  place 
approximately  10  tons  into  low  Earth  orbit. 

The  launch  center  of  NASDA,  Tanegashima  Space  Center  (TNSC), 
provides  the  necessary  preparation  and  support  for  the  H-II 
launch  vehicle.  TNSC  is  located  at  30  degrees  28  minutes  north 
latitude  allowing  for  resupply  missions  to  the  Space  Station 
with  limited  penalty.  The  general  accessibility  from  major 
industrial  regions  and  Japan's  large  cities  is  sufficient  to 
support  operational  activities  at  the  site.  The  Tanegashima 
island  has  an  extremely  stable  political  situation  as  a matter 
of  course.  The  new  launch  site  is  expected  to  accommodate  four 
launches  per  year. 

NASDA  is  now  studying  a growth  version  of  the  H-II  rocket  which 
will  be  adequate  for  Japan's  requirements  and  the  international 
context. in  the  2005  time  frame.  The  advanced  version  of  the 
H-II  rocket  will  be  required  to  be  compatible  with  the  Ariane  5 
and  the  Space  Shuttle,  with  a payload  diameter  of  4.6  meters 
and  two-fold  increase  in  payload  launch  capability.  NASDA 
requires  an  accessibility  to  the  Space  Station  which  will 
include  a reusable  spaceplane  of  15  to  20  tons.  Several 
improvements  to  the  basic  H-II  rocket  are  being  analyzed.  The 
roost  simple  improvement  can  be  performed  by  only  increasing  the 
number  of  SRB's  from  two  to  six,  resulting  in  approximately  a 
two  fold  increase  in  launch  capability.  Another  concept  of 
improvement  is  to  remove  the  second  stage  from  the  basic 
configuration  and  add  the  SRB's.  This  single  stage  version  may 
be  a more  promising  candidate  than  the  two  stage  one  for 
launching  the  spaceplane,  because  of  the  higher  reliability  and 
lower  launching  cost. 
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Soviet  Space  Vehicles 


In  the  25  year  history  of  spaceflight  the  Soviet  Union  has 
revealed  few  details  of  its  launch  vehicles.  It  is  therefore 
surprising  to  find  how  much  detailed  information  has  been 
painstakingly  assembled  by  Western  observers.  Their  task  has 
been  simplified  by  the  fact  that  there  have  been  few  completely 
new  Soviet  launchers,  especially  in  recent  years.  Developments 
have  consisted  of  additions  and  improvements  to  the  original 
military  missiles.  This  compares  with  the  much  faster  develop- 
ment of  rocketry  techniques  resulting  from  the  more  varied 
launchers  produced  by  the  competing  aerospace  companies  within 
the  United  States.  Since  launching  Sputnik  1 in  October  1957, 
the  Soviet  Union  has  relied  on  five  families  of  launch  vehicles 
to  orbit  more  satellites  and  space  probes  than  any  other 
nation.  To  the  West,  these  launcher  families  are  known  as  the 
A,  B,  C,  D,  and  F classes. 

Currently,  the  Soviet  Union's  largest  launch  vehicle,  the  D 
class  is  used  to  place  satellites  in  geostationary  orbit  or 
space  stations  in  low  Earth  orbit.  The  D launch  vehicle  (SL9) 
was  first  used  in  1965  to  launch  the  first  of  three  scientific 
satellites  which  gave  their  name  to  this  launcher  family,  the 
Proton.  The  Proton  versions  are  still  in  use.  The  Dl-h,  first 
flown  in  1970,  has  been  used  to  launch  Salyut  space  stations, 
where  the  D-l-e  is  used  to  launch  GEO  satellites. 

The  Soviet  Union  has  three  new  vehicles  in  the  final  stages  of 
development.  The  first,  a medium-lift  launch  able  to  place  a 
15-ton  payload  in  low  Earth  orbit,  weighing  400  tons  at 
lift-off  and  producing  600  tons  of  initial  thrust.  It  is 
reported  to  be  able  to  carry  a small  reusable  spaceplane  now 
under  development.  The  second,  a heavy-lift  launch  vehicle 
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capable  of  lifting  a 150-ton  payload  to  LEO.  Existence  of  the 
Saturn  V-class  heavy-lift  vehicle  has  fueled  speculation  that 
the  G-class  launch  vehicle  which  failed  spectacularly  in  tests 
between  1969  and  1972  might  finally  have  been  perfected.  The 
heavy-lift  launcher  will  feature  six  or  more  liquid-propellant 
strap-on  boosters.  Lift-off  thrust  is  estimated  at  4,000  tons, 
more  than  that  of  the  Saturn  V.  The  third  new  development 
consists  of  a Shuttle-type  launch  vehicle  comprised  of  a core 
stage  augmented  by  two  strap-on  G-class  boosters  and  carrying  a 
reusable  Orbiter-type  vehicle.  The  major  difference  between 
this  and  the  0.  S.  Space  Shuttle  is  that  the  Soviet  orbiter 
does  not  have  main  engines,  instead  these  are  located  on  the 
core  stage.  Estimates  have  the  Soviet  shuttle  at  a 1,500-ton 
gross  lift-off  weight,  generating  4,000-6,000  tons  of  thrust, 
and  can  carry  a 30-ton  payload  into  low  Earth  orbit 
(Figure  5-13). 

The  Soviet  shuttle  payload  capacity  is  about  65,000  pounds  with 
a cargo  bay  about  the  same  size  as.  the  0.  S.  Space  Shuttle. 
Drawings  released  by  the  Pentagon  show  the  Soviet  vehicle  lacks 
the  three  large  main  engines.  In  their  place,  the  Soviet 
designers  put  a pair  of  jet  engines  and  a limited  fuel  supply 
that  gives  their  vehicle  a "once-around"  capability  for  land- 
ing. Without  on-board  rocket  engines,  the  Russian  shuttle  will 
get  its  launch  power  from  the  SL-16,  class  G,  medium-lift 
boosters.  Also,  the  orbiter' s wing  tips  are  more  sharply 
angled  than  the  rounded  tips  on  the  U.  S.  Shuttle  allowing 
better  stability  during  atmospheric  flight. 

5.2  ORBITAL  MANEUVERING  VEHICLE  (OMV)  (IOC1991) 

The  OMV  is  a reusable,  remotely  controlled,  free-flying  vehicle 
capable  of  performing  a wide  range  of  on-orbit  services  in 
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support  of  orbiting  spacecraft  and  the  Space  Station  ( SS ) . The 
OMV  can  be  based  at  a Shuttle,  at  the  SS,  or  space  based. 

The  OMV  is  approximately  15  feet  in  diameter  and  4 feet  in 
length,  excluding  protuberances  such  as  trunnion  scuff  plated, 
retrieval  trunnions,  and  deployed  sensors  and  antennas.  The 
fully  loaded  vehicle  weights  approximately  13,000  pounds; 
standard  Payload  Accommodation  Equipment,  used  singly  or  in 
combination,  may  add  approximately  125  pounds  for  the  grapple 
docking  mechanism  and  150  pounds  for  the  three  point  docking 
mechanism.  ASI  weighs  approximately  125  pounds.  The  vehicle 
weight  includes  6600  pounds  for  usable  bipropellants  (NjO^/MMH) 
for  variable  thrust  orbit  adjust  engines,  1000  pounds  of 
hydrazine  (^H^)  for  the  monopropellant  RCS  system,  and  165 
pounds  of  nitrogen  for  the  cold  gas  RCS  system.  The  cold  gas 
RCS  system  can  be  used  for  close  proximity  operations  to  reduce 
spacecraft  contamination . 

The  design  of  the  OMV  is  illustrated  in  Figures  5-14  and  5-15.. 
Figure  5-14  depicts  the  extendable  RMS  Grapple  Docking 
Mechanism  for  securing  payloads  on  orbit  and  the  111  inch 
diameter  bolt  circle  for  accommodating  cantilevered  payloads. 
Not  shown,  but  also  available,  is  a mating  ring  with  latches, 
that  correspond  to  the  Multi-Mission  Module  Spacecraft  (MMS) 
Flight  Support  System  (FSS)  interface  hardware.  Also  shown  are 
the  docking  TV  and  the  deployable  viewing  TV,  radar,  and 
communications  antennas  used  to  support  payload  acquisition  and 
berthing . 

As  illustrated  in  Figure  5-15,  the  OMV  is  composed  of  two 
separable  modules;  the  Short  Range  Vehicle  (SRV)  incorporating 
the  OMV  RCS  and  avionics  equipment,  and  the  bipropellant 
Propulsion  Module  (PM).  Shown  on  the  SRV  are  the  body  mounted 
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Figure  5-14 
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SHORT  RANGE  VEHICLE  PROPULSION  MODULE 


solar  array  available  for  augmenting  OMV  battery  power  under 
favorable  mission  conditions.  The  SRV  is  very  modular, 
containing  10  avionic  ORU's  and  4 RCS  ORO's.  The  entire  PM  is 
an  ORO  which  permits  on-orbit  propellant  resupply  capability. 
The  PM  contains  four  continuously  variable  (13  to  130  pound) 
thrust  engines  and  the  6600  pounds  of  bipropellant.  While  the 
PM  provides  approximately  91  percent  of  the  total  impulse 
capability  of  the  OMV,  SRV  on-board  monopropellant  and  cold  gas 
RCS  systems  provide  the  SRV  with  a complete  functional 
capability  to  place,  rendezvous,  retrieve,  and  berth  payloads. 
At  approximately  4700  pounds,  fully  fueled,  the  SRV  can 
therefore  be  used  without  the  PM  for  smaller  mass  payloads  and 
missions  with  lower  orbital  maneuvering  requirements.  The  OMV 
is  capable  of  flying  on  the  Shuttle  either  fully  or  partially 
loaded  with  fuel. 

The  OMV  offers  the  following  standard  services  to  payloads:  a) 
Five  KWH  (1KW  Peak)  of  energy.  Additional  energy  may  be 
available  on  an  "as  available"  basis  or  by  the  negotiated 
addition  of  battery  kit,  b)  Limited  data  services  that  will  be 
implemented  via  hardware  interfaces  to  the  OflV  data  bus  and  the 
high  rate  data/video  data  channels,  and  c)  Attitude  orientation 
except  during  orbit  transfer  burns. 

Primary  control  of  the  OMV  will  be  from  a ground  station  via  a 
two-way  link  through  TDRSS.  When  based  at  the  Space  Station, 
control  for  close  proximity  operations  will  be  from  the  sta- 
tion. Other  than  for  the  final  rendezvous  and  docking  opera- 
tions which  require  TV-assisted  man-in-the-loop  control,  the 
OMV  is  capable  of  automatic  flight.  Communication  formats  and 
data  processing  are  compatible  with  TDRSS,  STDN,  and  ground 
processing  systems. 
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Orbital  Maneuvering  Vehicle  Performance 


A number  of  payloads  have  operational  altitude  requirements  in 
excess  of  the  Shuttle  injection  capability  or  require  deploy- 
ment from  the  SS.  Figure  5-14  (OMV)  and  Figure  5-15  (SRV)  show 
parametrically  payload  capability  as  a function  of  altitude 
above  the  base  (Shuttle/SS)  for  various  mission  scenarios.  The 
curve  labeled  "Delivery"  is  the  capability  to  deliver  a payload 
to  a higher  orbit,  while  the  "Retrieval"  curve  represents  the 
capability  of  the  OMV  to  depart  the  base  and  retrieve  a pay- 
load. 

The  curve  labeled  "Round-trip"  shows  the  capability  to  deliver 
a payload  or  servicing  kit  to  altitude,  then  return  it  to  the 
base.  The  lower  curve,  "Retrieval  and  Redeploy,"  indicates  the 
capability  to  retrieve  a spacecraft  to  the  Shuttle  or  SS  or 
servicing  followed  by  redeployment  to- its  operational  orbit. 

In  all  cases,  the  OMV  returns  to  the  base,  and  there  is  no 
plane  change. 

5.3  SPACE  STATION  TRANSPORTATION  SUPPORT  OPTIONS 
Shuttle 


The  report  of  the  NASA  mixed  fleet  study  team  states  throughout 
the  document  that  the  shuttle  vehicle  does  not  have  sufficient 
capability  to  support  the  up-mass  and  down-mass  requirements 
for  the  Space  Station  from 

With  the  current  Orbiter  fleet  of  three  vehicles  (possible 
four)  the  expected  flight  rate  will  only  be  about  14-16  flights 
per  year.  Use  of  other  vehicles,  such  as  SDVs,  expendables; 
etc.,  for  Station  missions  that  do  not  require  man  would 
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relieve  the  scheduling  load  on  the  Shuttle.  The  Shuttle  and/or 
its  replacement  Shuttle  II  should  still  be  used  for  crew 
rotation. 

Shuttle  and  OMV 

Orbital  Maneuvering  Vehicle  (OMV)  Requirements 

The  OMV  is  necessary  to  support  typical  Space  Station  opera- 
tions, and  will  provide  on-orbit  mobility  to  the  Space  Station 
in  the  operational  era.  It  will  be  used  to  deploy  unmanned 
platforms  to  operational  altitudes,  retrieve  for  maintenance, 
redeploy  spacecraft  and  large  observatories,  and  support  a wide 
variety  of  proximity  operations.  Typical  missions  to  be 
performed  include  module/element  transfer  from  low  orbit  to  the 
Space  Station  orbit  (Shuttle  or  Cargo  Vehicle)  and  deorbiting 
of  cargo  return  vehicles. 

Cargo  Return 

The  ability  to  return  cargo  in  some  manner  other  than  the 
Shuttle  is  necessary.  One  of  the  most  attractive  is  to  use  a 
Cargo  Return  Vehicle  derived  from  the  Crew  Emergency  Return 
Vehicle.  Use  of  the  same  configuration  would  lower  development 
effort  of  a specialized  cargo  vehicle,  and  at  the  same  time 
help  to  prove  the  CERV  concept  and  provide  "practice"  in  the 
event  of  an  emergency  situation.  Use  of  a precision  land 
recovery  system  could  be  used  in  cases  of  delicate  and  expen- 
sive cargo  return,  such  as  critical  experiment  results  or 
pharmaceuticals . 

Another  option  to  be  considered  for  cargo  return  is  use  of 
non-station  Shuttle  flights  of  opportunity  that  go  to  the  same 
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orbital  inclination  as  the  Station.  This  method  requires 
considerable  effort  in  orbit  matching,  but  may  occasionally  may 
be  beneficial. 

Rescue  Options 

The  ability  to  rapidly  rescue  the  entire  crew  from  a disabled 
Space  Station  is  a major  requirement.  The  safe  haven  capabili- 
ty that  is  to  be  provided  on  the  Space  Station  cannot  provide 
complete  coverage  of  all  failure  modes,  an  alternate  means  for 
rescue  roust  be  provided.  Rapid  return  to  Earth  of  a seriously 
ill  crewman  is  also  desired  so  proper  medical  attention  can  be 
obtained. 

Several  options  have  been  considered  for  crew  rescue,  including 
the  Space  Shuttle,  a specifically  tailored  Station  based  rescue 
capability,  and  the  possibility  of  foreign  support. 

Shuttle  Only 

The  current  baseline  method  of  crew  rescue  is  to  use  the  Space 
Shuttle  as  it  exists  today  with  a turn-around  time  frame  of  28 
days.  In  the  event  of  an  emergency,  the  priority  of  the 
manifested  payload  could  be  overridden  by  the  need  to  perform 
the  rescue  mission. 

There  are  several  avenues  to  this  problem: 

1.  Payload  in  Cargo  bay 

a.  Leave  the  payload  in  the  cargo  bay  and  immediately 
begin  to  make  necessary  changes  to  flight  software; 
etc.,  to  perform  the  rescue  mission.  Although  this  is 
probably  the  fastest  of  any  of  the  Shuttle  options,  the 
one  problem  that  could  arise  is  that  the  payload  may 
exceed  the  lift  capability  of  the  Space  Shuttle  to  the 
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Space  Station  orbit.  Another  problem  could  be  the  time 
involved  in  changing  the  flight  software  for  the  new 
mission.  This  option  is  also  highly  dependent  upon  the 
point  in  the  ground  processing  flow  when  the  call  for 
rescue  comes  in.  The  flight  crew  would  need  to  be 
reduced  to  provide  space  for  the  Station  crew  to  be 
rescued.  Even  here,  the  entire  station  crew  cannot  be 
rescued  and  multiple  Shuttle  crew  rescue  missions  would 
be  required  to  complete  the  mission. 

b Deintegrate  the  cargo  that  is  on  the  Shuttle.  This 
option  would  only  be  viable  in  the  event  of 
non-catastrophic  failure  at  the  Space  Station  because 
of  the  time  required  to  accomplish  the  complex  ground 
flow.  If  the  Shuttle  is  on  the  pad,  the  payload  would 
be  deintegrated  using  RSS/PCR,  possibly  some  type  of 
rescue  module  put  in  the  cargo  bay,  and  then  launched. 

2.  Orbiter  on  Standby 

This  option  would  be  the  most  effective  from  a rapid 
response  standpoint,  but  is  not  feasible  from  a cost  and 
schedule  position. 

3.  Orbiter  on  Orbit 

An  Orbiter  on  orbit  for  another  mission  is  probably  the 
most  attractive  responsively,  but  is  also  the  roost 
unlikely.  With  only  one  mission  per  month  predicted  with 
a seven  day  nominal  duration,  an  Orbiter  is  on  orbit  only 
about  25%  of  the  time.  Also,  the  possibility  of  orbits 
matching  at  the  time  of  rescue  is  extremely  remote. 

Crew  Emergency  Return  Vehicle 


The  Crew  Emergency  Return  Vehicle  (CERV)  would  be  station  based 
with  the  ability  to  berth  at  any  port  on  the  Space  Station. 

The  CERV  would  be  moved  about  the  Station  using  the  MMRS  or  the 
OMV . The  CERV  would  require  Space  Station  power,  heat  rejec- 
tion, data  management,  telemetry,  state  vector  updates,  status 
monitoring,  and  maintenance  item  stowage.  The  CERV  would  be 
automated  with  a recovery  in  the  ocean  within  24  hours  by  ship 
of  opportunity.  The  CERV  would  have  a shirtsleeve  environment 
and  medical  provisions,  as  shown  in  Figure  5-16. 
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The  goals  of  the  CERV  dictate  that  it  minimize  impact  to  the 
Station  design  and  minimize  required  training  to  the  crew  for 
utilization.  The  on-orbit  storage  lifetime  must  be  very  long, 
and  the  on-orbit  test,  checkout,  monitoring,  and  maintenance 
must  be  simplified.  The  goal  for  crew  recovery  after  splash- 
down is  90  minutes,  with  delivery  to  a definitive  medical 
facility  within  two  hours. 

Rescue  Recommendation  Options 

A recognized  need  for  a Crew  Emergency  Return  Vehicle  exists 
due  to  threats  to  crew  health  and  safety  and  possibilities  of 
extended  Shuttle  turnaround  time.  An  assessment  by  a NASA 
Johnson  Space  Center  has  recognized  12  of  20  threats  leading  to 
crew  escape  potential.  The  safe  haven  concept  does  not 
accommodate  all  failure  and  rescue  scenarios.  The  safe  haven 
approach  is  still  required  but  can  be  improved  by  the  addition 
of  a CERV.  The  CERV  could  also  be  used  in  a secondary  role  as 
an  orbital  ambulance  in  the  case  where  an  immediate  return  is 
required  for  severe  medical  care. 

The  concept  of  an  escape  vehicle  for  emergency  evacuation  of 
Space  Station  crew  members  is  strongly  recommended  as  a life 
saving  measure  in  case  of  a catastrophic  event  which  would 
compromise  the  ability  of  the  Space  Station  to  support  vital 
crew  needs.  It  is  also  recommended  that  medical  requirements 
be  integrated  into  the  design  of  the  CERV  such  that  it  would 
complement  the  capability  in  the  Health  Maintenance  Facility 
and  would  allow  appropriate  medical  treatment  for  a subgroup  of 
injuries  and  illnesses  whose  prognosis  would  be  poor  without  an 
immediate  return  capability. 
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A review  of  Shuttle  ground  processing  cannot  always  support  a 
28  day  rescue  option.  The  worst  case  scenario  requires  45  days 
for  rescue.  It  is  recommended  that  the  safe  haven  capability 
be  increased  from  28  to  45  days  minimum. 

The  foreign  shuttle  vehicles  are  recommended  only  as  a backup 
to  the  rescue  vehicle.  The  dependance  on  foreign  shuttle 
systems  to  be  prepared  in  a reasonable  time  frame  for  rescue 
would  unlikely  be  realized.  If  the  foreign  shuttles  have 
demonstrated  an  operation  capability  with  a short  turn-around 
vehicle,  the  vehicles  may  be  involved  more  in  the  emergency 
rescue  scenario. 

Escape  methods  have  been  an  essential  part  of  almost  every 
hazardous  manned  program  to  date  when  technically  feasible. 

The  CERV  would  provide  a critical  capability  that  can  meet  the 
requirements  of  evacuation  of  station  crew,  medical  evacuation 
of  crewmembers,  and  Shuttle  grounded  .scenarios.  The  effect  on 
the  crew  of  not  having  a CERV,  even  if  not  needed,  may  be  an 
increase  in  stress  and  lower  performance  over  time.  If  the 
CERV  is  not  provided  but  needed,  the  effect  would  be  devastat- 
ing to  the  space  program,  and  could  require  costly  rescue 
efforts  that  may  not  be  successful. 

5 . 4 SUMMARY 

The  capability  of  the  United  States  and  the  International 
Partners  is  considerable  and  versatile;  however,  there  are 
several  basic  premises  that  need  to  be  established  in  order  to 
insure  that  the  most  effective  and  flexible  options  will  be 
available  in  the  year  2010. 

Since  the  National  Space  Transportation  System  (NSTS)  will 
always  be  in  great  demand  for  NSTS  unique  missions  and  manned 
missions,  the  basic  concept  of  resupply  to  the  Space  Station  by 
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unmanned  expandable  vehicles  must  be  incorporated  into  the 
basic  philosophy  of  the  SSP.  Manned  resupply  should  only  be 
undertaken  for  those  missions  that  specifically  require 
"man-presence".  The  inherent  cost  factor  of  a manned  resupply 
would  tilt  the  scales  toward  unmanned,  but  the  real  factor 
comes  from  the  risk  of  manned  vs.  unmanned  launch.  Also,  the 
International  Partners  will  be  able  to  be  more  fully  involved 
with  the  SSP  if  the  resupply  missions  utilize  International 
unmanned  launch  vehicles.  International  launch  vehicles  could 
also  be  utilized  as  a method  of  "barter-exchange”  for  like 
services  of  the  NSTS  and  other  United  States  launch  vehicles. 
The  International  politics  of  such  SSP  operations  would  be  no 
small  factor  in  such  a premise. 

One  of  the  most  important  findings  during  the  study  was  that  a 
Crew  Rescue  Vehicle  will  be  required  at  the  Space  Station  at 
all  times  unless  a Space  Shuttle  is  available  as  an 
alternative.  A variation  of  the  CERV  which  could  be  used  for 
an  alternate  Logistics  Module  showed  some  merit.  The 
combination  vehicle  would  undoubtedly  save  resources  while 
allowing  a more  flexible  type  of  operations. 

The  study  of  the  Transportation  Services/Rescue  area  of 
operations  for  the  SSP  during  the  next  century  showed  that  the 
supply/resupply  transportation  costs  and  the  associated  ground 
operations  costs  could  rival  the  cost  of  the  on-station 
activities;  therefore,  it  is  mandatory  to  establish  the  proper 
planning  early  and  to  explore  new  and  innovative  transportation 
concepts  during  the  design  phase  of  the  SSP. 
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6.0  INFORMATION  SYSTEMS  AND  COMMUNICATION 


The  complexity  of  the  operation  of  the  Space  Station,  its 
physical  remoteness  (i.e.,  in  orbit),  the  continuing  change  of 
mission  as  new  experiments  are  taken  up  to  the  station,  and  the 
importance  of  safety  and  reliability  all  place  heavy  burdens  on 
the  requirements  for,  and  importance  of,  ground  information  and 
communications  systems.  User  needs  for  access  to  their 
experiments  either  in  ground  test  facilities  or  in  the  station 
or  orbit  and  the  associated  data  will  also  rely  on  these 
systems  to  some  extent.  The  proper  implementation  and 
operation  of  these  systems  will  contribute  significantly  to  the 
overall  effectiveness  of  Space  Station  operations  both  in  the 
short  term  and  the  long  term. 

6.1  EXECUTIVE  SUMMARY 

The  Information  and  Communications  Systems  during  the 
Operational  phase  of  the  SSP  must  be  highly  integrated  with  the 
many  computer  systems  networked  for  the  sharing  of  data  on  a 
large  scale.  There  must  be  interfaces  between  all 
organizational  aspects  of  the  program  - flight  operations, 
ground  processing,  logistics,  sustaining  engineering,  etc.  To 
do  this,  planning  must  be  initiated  now  to  eliminate  pockets  of 
"uniqueness"  whether  generated  because  of  desire  to  stay  with 
old  systems  or  because  of  political  boundaries.  To  do  this  a 
high  level  of  control  must  be  in  place  to  manage  database  and 
network  architecture  and  design  which  includes  management 
commitment  to  see  that  it  is  implemented.  Artificially  created 
political  boundaries  can  only  be  broken  with  high  level  of 
management  commitment. 
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Evolution  must  be  planned  for  all  operational  information 
systems.  Budget  projections  seen  at  this  time  exclude  capital 
costs.  If  these  capital  costs  are  not  planned  for,  we  will 
have  archaic,  unmanageable  data  systems  which  do  not  support 
the  operational  program. 

6.1.1  Program  Requirements 

In  order  to  sustain  a stable  long  term  operation  which  has  a 
capability  to  evolve  and  grow,  a number  of  requirements  must  be 
adhered  to  by  all  computer  and  communications  system  elements 
supporting  the  program. 

Hardware/Software  Commonality  and  Standards.  Organizations  are 
spending  up  to  80  percent  of  their  software  budget  on  mainte- 
nance costs  alone.  Also,  up  to  85  percent  of  the  acquisition 
cost  of  a system  is  the  cost  of  the  software  alone — not  the 
hardware.  In  order  to  control  costs  in  the  information  systems 
for  the  operations  of  Space  Station,  software  commonality  and 
standards  must  be  stressed.  This  will  allow  different  software 
systems  to  communicate  more  easily  by  eliminating  interface 
problems,  it  will  provide  a simplified  method  of  transporting 
software  from  one  application  to  another,  eliminate  costs 
associated  with  generation  of  duplicate  code  to  perform  the 
same  function,  and  minimize  duplicate  entry  of  the  same  data 
into  separate  systems.  By  decreasing  the  amount  of  unique 
software  generated,  the  costs  for  maintenance  goes  down.  By 
adhering  to  a set  of  software  development  standards, 
maintenance  costs  are  also  decreased  because  fewer  software 
specialists  are  required  - there  is  more  sharing  of  software 
personnel  between  systems. 
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There  is  an  initial  acquisition  cost  increase  with 
standardization  as  well  as  some  performance  penalty.  The 
acquisition  (or  development)  cost  increase  is  associated  with 
having  to  meet  the  standards.  This  cost  is  quickly  recovered 
thru  utilization  of  common  software  elements  in  multiple  sites 
within  the  SSP.  The  performance  penalty  is  associated  with  not 
being  able  to  "tune"  a software  system  for  its  specific 
application.  With  the  rapidly  increasing  capability  in 
computer  hardware,  this  performance  penalty  generally  is  not  a 
problem.  Specific  exceptions  should  be  dealt  with  on  a 
case-by-case  basis  with  approval  being  required  at  as  high  a 
level  as  possible  because  of  future  cost  implications.  A 
manager  who  is  trying  to  meet  performance,  schedule  and  cost 
criteria  during  development  will  generally  not  adequately 
address  maintainability  of  a system. 

While  hardware  commonality  is  not  required,  communication  and 
interface  standards  are.  Selection  of  hardware  which  does  not 
support  the  program's  interface  and  communication  standards 
should  not  be  permitted  within  the  system.  With  the  drive 
toward  industry  standards,  this  should  not  be  a problem  during 
the  operations  era. 

The  SSP  is  addressing  software  commonality  and  standards  thru 
the  development  of  the  Software  Support  Environment  discussed 
previously.  There  are  many  systems  which  are  considered 
" institutional " systems  and  not  within  the  management  control 
of  the  SSP.  It  is  important  that  these  systems  also  have 
commonality  and  standardization  extended  to  them  to  the 
greatest  extent  possible.  They  should  be  encouraged  to  evolve 
into  the  use  of  SSP  standards  and  SSE.  Wherever  possible,  the 
SSP  should  encourage  agency-wide  standardization.  The  SSP 
should  unify  its  own  position  on  standards  and  commonality  and 
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should  have  a centralized  group  to  design  the  overall  system 
architecture  to  assure  that  a cohesive  system  is  designed 
without  the  isolated  pockets  of  individuality  created  by 
organizations  creating  empires  or  asserting  their  independence. 

Communications  Standards . Within  the  last  two  decades 
telecommunication  services  have  cascaded  dramatically.  Much  of 
this  growth  has  developed  to  support  remote  information 
processing  and  has  grown  in  response  to  its  physical 
transmission  standards.  In  most  cases  the  transmission  method 
was  telephone  pair  and  early  communications  standards  developed 
around  AT&T  products  ( in  the  0 . S . ) and  the  CCITT  standards  ( in 
Europe ) . 

The  other  driver  in  the  development  of  communication  standards 
has  been  the  hardware  vendors  themselves.  IBM  and  DEC  as  the 
two  largest  equipment  manufacturers  in  the  United  States  have 
driven  the  communications  standards  with  proprietary  products. 
With  the  IBM  market  place  the  IBM  3270  protocol  and  now  SNA 
have  become  defacto  standards  for  communications  - not  because 
of  their  ability  to  communicate  efficiently  but  because  of 
their  proprietary  nature.  This  has  forced  large  networking 
endeavors  to  become  proprietary  (IBM  or  IBM  compatible).  In 
view  of  the  Federal  Acquisition  Requirements  (FAR)  and  GSA's 
non-sole-source  requirements  this  is  not  an  acceptable 
solution. 

In  1977,  the  International  Standards  Organization  began  to 
address  the  problem  of  networking  diverse  computer  systems  and 
developed  the  Open  Systems  Interface  (OSI)  Model.  The  OSI 
Model  is  a seven  layer  model  where  the  lowest  three  layers  are 
classical  communications  functions.  In  the  OSI,  each  layer 
communicates  to  only  the  layers  immediately  above  and  below 
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itself.  In  all  cases,  the  interactions  between  layers  are 
controlled,  not  the  layer's  internal  functions.  In  this 
fashion,  manufacturers  can  supply  equipment  and  software  to 
provide  an  OSI's  layer  functionally.  Therefore,  data  can  flow 
through  a network,  independent  of  topology,  manufacturer  or 
technological  level  of  the  communications  equipment  involved. 

Currently,  the  CCITT's  X.25  (employed  in  the  NASA  Packet 
Switched  System)  meets  the  OSI  model  layer  three  and  represents 
the  type  of  protocol  that  Space  Station  Ground  Operations  must 
employ.  Unless  a standard  like  X.25  is  used,  the  program  will 
be  locked  into  a specific  communication  technology  and  solution 
that  will  be  difficult  (if  not  impossible)  to  maintain  and 
operate . 

The  selection  of  proper  standards  will  allow  orderly  connection 
of  international  users,  commercial  firms  and  experimenters. 
Adherence  to  international  standards  will  also  allow  the 
program  to  evolve  over  its  lifetime  and  support  infusion  of  new 
technologies  into  the  ground  supporting  network. 

It  should  be  noted  that  adherence  to  a specific  standard  will 
not  insure  trouble  free  connections  to  all  users.  For  example, 
the  Federal  Information  Processing  Standard  (FIPS)  86  allows 
vendor  specific  bit  utilization  and  the  EIA's  RS-232-C  allows 
pin  specific  vendor  applications.  However,  if  widely  accepted 
protocols  are  utilized,  conversion  from  vendor  specific 
applications  is  usually  readily  available. 

Another  difficulty  in  Standard  Selection  is  the  required 
commitment  to  maintain  the  latest  revision  of  that  standard. 
Standards  evolve  over  the  course  of  a thirty  year  program  and 
management  planning  must  include  costing  to  maintain  software 
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and  hardware  at  the  current  industry  revision.  This  problem  is 
one  that  faces  the  agency's  institutional  roles,  but  usually 
not  programmatic  management. 

Security  and  Data  Integrity.  The  capability  of  "hackers"  and 
"HBO  Bandits"  to  penetrate  information  and  communications 
systems  (ICS)  has  been  demonstrated.  Even  without  the  presence 
of  classified  data,  there  is  a need  to  recognize  the 
requirement  for  security  within  the  ICS.  This  requirement 
should  be  recognized  and  designed  for  early  in  the  program. 

Since  most  security  systems  which  have  been  designed  can  be 
broken,  the  amount  of  risk  that  is  acceptable  for  each  element 
of  the  ICS  should  be  determined  early  to  allow  for  the  security 
to  be  implemented  in  the  design  and  development  phase.  Failure 
to  do  so  will  result  in  exorbitant  costs  for  retrofitting/de- 
signs to  accommodate  security. 

Risk  Analysis  and  Vulnerability  Assessments  must  be  planned, 
scheduled  and  implemented  throughout  the  design,  development 
and  operational  phases  of  the  program.  The  impact  of  a 
"hacker"  altering  data  in  the  system,  even  in  an  "off-line" 
system  can  be  extremely  expensive  if,  for  instance,  some 
required  supplies  are  not  available  on  the  right  schedule  to 
support  a launch.  With  increasing  levels  of  automation, 
detection  of  system  penetration  becomes  more  important. 

Physical  security  must  also  be  addressed  from  day  one.  Physical 
access  control  to  data  centers,  disaster  recovery  libraries, 
backup  libraries,  communications  centers  and  terminal  areas  are 
necessary  as  a minimum  step. 
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Physical  access  to  Data  Centers  may  be  controlled  by  several 
methods.  Each  site  should  select  the  appropriate  method  based 
on  its  own  requirements,  all  within  the  guidelines  of  a minimum 
NASA-wide  policy.  An  ever  present  security  guard  may  be 
desired  for  a high  risk  area.  Where  non-classif ied, 
non-sensitive,  and  non-proprietary  data  is  housed,  an 
electronic  badging  system  or  a combination  lock  system  may  be 
chosen  as  a cost  effective  feature.  Whatever  the  accepted  risk 
is,  no  unauthorized  personnel  should  ever  be  in  the  Data 
Center. 

Security  in  the  communications  environment  is  a difficult  task. 
The  International  Standards  Organizations'  (ISO)  Open  Systems 
Interface  Model  does  not  address  security  in  the  communications 
Levels  (although  a revision  is  addressing  the  problem),  thereby 
leveling  security  requirements  on  the  computer  systems. 

However,  military  and  increasingly  industrial  users  have 
security  requirements  for  classified,  proprietary,  and/or 
sensitive  data.  This  security  includes  requirements  for 
encryption  (simple  to  complex)  and,  in  the  military 
applications,  line  protection  and  shielding  to  avoid  radio 
frequency  transmission  of  classified  data.  Although  the  ISO 
Model  does  not  include  security  in  the  communications  phase,  it 
does  not  preclude  the  user  from  encrypting  and  decrypting  his 
data. 

No  requirements  have  been  forthcoming  to  identify  the  need  for 
a high  level  data  protection  mechanism.  It  is  the  opinion  of 
the  panel  that  requirements  will  emerge  to  at  least  protect 
vendor  proprietary  software  and  serious  consideration  of  this 
must  be  taken  into  account  now. 


The  SSP  decision  to  not  provide  security  was  cost-driven. 
Consideration  of  the  operational  cost  impact  of  system 
penetrations  should  be  done  to  counterbalance  this  decision. 

Growth  and  Evolution.  Recent  history  has  shown  that  the  use  of 
computers  and  the  associated  communication  systems  is  growing 
at  a rapid  rate.  At  the  same  time,  technology  in  this  area  is 
changing  swiftly,  both  hardware  and  software.  In  order  to 
maximize  the  effectiveness  of  the  Space  Station  while 
controlling  costs,  the  information  systems  must  be  structured 
to  grow  and  evolve  to  meet  the  increasing  user  needs  on  the 
systems . 

Of  primary  importance  in  this  area  is  planning.  Data  bases  and 
systems  must  be  planned  during  the  development  phase  to  allow 
for  expansion  without  having  to  regenerate  all  of  the 
application  software.  The  data  bases  should  be  designed  with 
future  requirements  for  more  automation  in  mind  and  more 
complex  integration  of  tasks,  increasing  the  interrelationship 
among  the  data.  Much  of  today's  planning  for  TMIS  is  based  on 
the  station  development  era,  with  little  or  no  mention  of 
operations.  Today's  planners  are  only  looking  at  today's 
problems  and  not  trying  to  plan  for  the  long  haul . It  is  of 
utmost  importance  that  an  operations  concept  be  folded  into  the 
TMIS  design  philosophy  for  future  system  evolution.  Without 
this  planning,  adequate  scarring  will  not  be  provided  for  ease 
of  future  evolution. 

Hardware  evolution  is  also  important.  Although  industry  has 
realized  the  criticality  in  being  able  (and  planning  to) 
replace  their  computer  hardware,  NASA  as  a whole  has  not 
acknowledged  this.  Some  of  the  reasons  for  planning  system 
upgrades  to  incorporate  new  technology  are: 
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o Avoid  maintenance  problems  associated  with  the 
availability  of  parts  for  obsolete  hardware 

o Gain  access  to  new  software  development  tools 

o Avoid  having  systems  software  which  is  no  longer  being 
maintained/ supported 

o Avoid  increased  maintenance  costs 

o Avoid  degradation  of  system  reliability 

These  reasons  are  all  acknowledged  as  being  drivers  for 
replacement  of  obsolete  hardware  in  the  Federal  Information 
Resources  Management  Regulation  (FIRMR).  The  FIRMR  also 
requires  periodic  review  of  equipment  for  obsolescence. 

System  design  and  implementation  should  plan  on  future  hardware 
replacement.  Some  techniques  to  accomplish  this  are: 

o Avoid  uniquely  designed  interfaces 
o Ose  transportable  languages  whenever  possible 
o Avoid  using  unique  capabilities 

o Avoid  "homegrown”  operating  system  changes  which  would 
have  to  be  recoded  for  new  hardware 

Budget  planning  is  a key  element  in  allowing  for  system 
upgrades — both  for  hardware  and  for  software.  Since  computer 
system  upgrades  should  be  a planned  activity,  the  program 
should  include  a steady  level  of  budget  authority  specifically 
devoted  to  system  replacement  not  just  adding  to  existing 
systems.  An  accountability  system  should  also  be  implemented 
which  tracks  that  the  money  is  being  spent  on  replacement  to 
avoid  the  problems  of  obsolescence. 


This  budget  planning  will  work  for  systems  which  are  under  the 
total  control  of  the  SSP.  Problems  will  arise  for 
institutional  or  shared  systems.  Systems  which  are  funded 
jointly  by  other  "operational"  programs  can  be  influenced  by 
having  a common  philosophy  across  the  Agency  operations 
organization. 

It  is  strongly  recommended  that  the  Agency  institute  a policy 
which  would  require  all  programs  and  all  institutions  be 
required  to  budget  for  capital  replacement  as  well  as  for 
operations  and  maintenance  of  their  information  systems. 

6.1.2  Data  Bases.  Processing  and  Interface  Requirements 

Each  element  of  ground  operations  requires  computer  support  to 
do  specific  functions  which  require  access  to  a variety  of  data 
bases.  Of  primary  importance  among  the  many  program  data  bases 
is  integration  across  the  program.  This  integration  must  be 
started  now  in  the  .early  stages  of  the  station  development 
rather  than  after  a majority  of  the  data  bases  are  built  and 
populated  when  we  get  into  the  operations  era.  The  complexity 
and  large  numbers  of  interfaces  between  functional  areas  and 
various  data  bases  are  illustrated  on  a high  level  in  the 
Supplemental  Data.  To  accomplish  the  level  of  integration 
required,  strong  program  management  must  be  exercised  at  Level 
A and  the  Program  Office  to  assure  all  elements  of  the  SSIS  are 
developed  with  a consistent  set  of  standards,  common  or 
compatible  data  base  management  systems  and  a common  data 
dictionary.  A review  of  planned  information  systems  should  be 
accomplished  as  soon  as  possible  to  eliminate  duplication  of 
common  functions.  An  example  of  this  is  the  plan  for  TMIS, 

GDMS  and  SSSC  to  provide  configuration  management  and 
documentation  production  capabilities.  Having  independent 
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documentation  production  capabilities  will  result  in  added 
overhead  when  intercenter  review  is  required.  It  will  also 
drive  additional  software  acquisition  and  software  maintenance 
costs.  If  duplicate  capabilities  are  required  because  of 
operational  considerations,  common  software  should  be  utilized 
for  these  capabilities  to  the  greatest  extent  possible.  This 
will  improve  the  capability  to  share  data  in  the  future  and  to 
consolidate  operations.  Where  use  of  common  software  is  not 
possible,  specific  common  formats  for  data  should  be  specified 
for  the  transferal  of  the  data,  otherwise  the  data  may  prove 
difficult,  if  not  impossible  to  use. 

When  the  Work  Package  contracts  are  awarded,  steps  should  be 
taken  to  assure  that  the  work  package  contractors  utilize  the 
common  TMIS  capabilities  or  other  program  provided  capabilities 
to  the  maximum  extent  possible  rather  than  company  (often 
proprietary)  systems.  This  will  improve  the  capability  to 
transfer  this  data  to  a sustaining  contractor.  It  will  also 
improve  integration  of  the  contractors'  products. 

There  appears  to  be  a continuing  proliferation  across  the 
agency  of  each  Center  and  each  organization  needing  to  "do  his 
own  thing".  They  feel  a need  to  have  their  own  computer  system 
that  processes  their  way  and  to  have  total  control  of  their 
data.  This  must  be  stopped  in  order  to  have  a system  which 
will  be  effective  during  the  operational  time  frame  and  to 
assure  maximum  integration/ sharing  of  data  is  facilitated. 

In  addition  to  requirements  for  integration  of  the  many  data 
bases,  specific  requirements  for  processing  and  data  bases  are 
associated  with  each  of  the  major  areas  of  ground  operations. 
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The  major  requirements  are  specified  here  with  the  required 
facilities  to  do  this  processing  and  data  base  maintenance. 

Logistics  and  Resupply.  The  Logistics  and  Resupply  functions 
including  Return  are  the  drivers  for  the  entire  Space  Station 
Project.  If,  in  fact.  Logistics  requirements  are  not  taken 
into  account  as  a "First”  step,  the  project  will  be  less  than 
adequate.  Frequency  of  flights,  number  and  mix  of  crew, 
supply,  resupply,  return,  upweight,  downweight,  etc.  will  be 
determined  by  logistics  requirements.  The  possibility  for  an 
ELV  option  rather  than  a pure  STS  environment  will  add  even 
more  credence  to  logistics  being  the  drivers. 

Just  as  Logistics  dictate  other  factors  it  most  certainly  is 
the  critical  requirement  for  an  ICS  integrated  database 
interface  utilizing  communication  standards  through  common 
software. 

Logistics  is  an  unforgiving  circle.  Database  requirements  will 
be  generated  by  user  requirements,  system  design,  SS 
configuration,  maintenance,  crew  procedures  and  NSTS  capability 
to  mention  a few  factors.  The  Logistics  Information  System 
(LIS)  Database  must  at  least  consist  of  item  (ID,  Category, 
State,  Quantity,  Usage,  Rate),  physical  characteristics, 
environmental  requirements,  resource  requirements,  orbital 
support  equipment /flight  support  equipment,  requirement  source 
and  pertinent  remarks  based  on  the  requirements.  In  addition 
information  is  required  on  maintenance  resources  such  as 
maintenance  documentation  and  production,  life  cycle  costs, 
repair  costs,  failure  history/trend  analysis  and  repair 
costs/time  vs.  new  buy/time  analysis.  Influence  is  then 
exerted  on  the  Database  by  logistics  element  design  concepts, 
storage  requirements,  crew  operations,  customer  accommodations. 
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internal  module  configuration,  design,  ground  processing, 
flight  manifesting  and  frequency  which  in  turn  establishes  the 
original  Database  requirements.  These  interfaces  illustrate  a 
need  for  the  LIS  to  be  tightly  coupled  with  the  configuration 
management  system,  sustaining  engineering  drawing  system, 
manifesting /scheduling  systems  for  flight/ground  processing, 
and  safety/reliability/quality  assurance  systems.  This  type  of 
scenario  completes  a very  fragile  and  demanding  circle  that  can 
only  be  satisfied  by  an  integrated  database.  Extensive  long 
range  planning  and  scheduling  must  be  exercised  at  all  levels 
to  maintain  the  delicate  balance  necessary  to  process  the  heavy 
and  intricate  logistics  requirements. 

Logistics  itself  is  addressed  daily  by  NASA,  DoD  and  large 
commercial  ventures.  The  Space  Station,  however,  will  induce 
an  additional  Logistics  scenario  previously  unnecessary. 

Regard  less  of  the  eventual  buzz  word  used  (Downmass, 
Downweight,  Return,  etc.)  careful  and  diligent  preparation  must 
be  addressed  to  meet  unique  Logistics  database  requirements. 

Ose  of  a common  Integrated  Database  by  all  contributing 
organizations  is  a mandatory  requirement.  The  LIS  should  be  at 
a minimum  a menu  driven,  user  friendly,  integrated  system  which 
provides  a means  of  collection,  analysis  and  summation  of 
requirements.  Failure  to  plan  for  the  massive  user  access 
paths  to  various  types  of  information  and  transaction 
capabilities  via  an  integrated  database  will  produce  the  normal 
bottleneck  common  to  logistics. 

All  phases  (Execution,  Tactical,  Strategic)  of  the  Space 
Station  must  budget  for  the  extremely  heavy  logistics 
requirements.  Present  logistics  capacities  and  capabilities 
were  not  designed  to  accommodate  this  additional  logistics 
magnitude.  It  is  imperative  that  all  logistics  be  a common 
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effort  utilizing  common  interfaces.  If  any  organization  fails 
to  coordinate  their  efforts  with  all  concerned  the  reinvention 
of  the  "logistic  wheel”  will  commence  again.  The  Space  Station 
budget  and  schedule  cannot  be  met  with  this  independent 
attitude.  A precise  and  integrated  coordination  of  all 
logistics  requirements  must  be  managed  at  the  Program  Office 
level  to  assure  fulfilment  of  Space  Station  needs  versus  piece 
meal,  duplicating,  costly  logistics  empire. 

Since  a large  amount  of  the  data  required  to  populate  an 
integrated  LIS  database  is  produced  during  the  design  phase 
(i.e.,  the  logistics  spares  analysis  records),  planning  for 
this  system  must  commence  immediately  and  not  be  deferred  until 
LMRT.  Deferral  of  this  system  will  result  in  fragmented  data 
produced  in  a multitude  of  formats  from  the  different  work 
packages  that  will,  at  best,  be  difficult  and  costly  to 
integrate. 

Although  inventory  management  is  a key  element  in  the  LIS,  the 
existence  of  KIMS  (Kennedy  Inventory  Management  System)  should 
not  be  allowed  to  drive  the  design  of  the  LIS.  The  LIS  should 
be  designed  to  support  a dynamic,  highly  integrated  long  range 
program.  Only  if  the  resulting  design  can  accommodate  the 
existing  system  without  compromising  the  overall  effectiveness 
of  the  system  should  the  SSP  consider  the  use  of  KIMS. 

Sustaining  Engineering  and  Configuration  Management.  The 
primary  computer  system  support  required  for  sustaining 
engineering  can  be  categorized  into  five  major  functional 
areas : 

a.  Drawing  and  design  analysis  support  (CAD/CAE/CAM) 

b.  Engineering  analysis,  including  performance  analysis, 
trend  analysis,  and  failure  analysis 
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c.  Software  development  support 

d.  Simulation 

e.  Configuration  Management 

In  addition,  in  order  to  perform  these  functions,  access  to  a 
number  of  data  bases  is  required 

o Anomaly  data 

o Station  and  ground  operation  history  data 

o Design  data  including  drawings,  parts  data, 
performance  data,  commonality  data 

o LRO/ORD  history  including  failure/performance  history, 
time  and  cycle  data,  repair  history 

o Configuration  data  including  as  built  and  as  designed 
configurations 

o Schedules 

Assuming  a centralized  sustaining  engineering  organization, 
this  organization  will  require  a TMIS  CAD/CAM/CAE  capability 
for  (a)  above,  an  engineering  analysis  facility  for  (b)  above, 
a soft  ware  development  facility  (SDF)  for  (c)  and  a simulation 
facility  which  may  be  co-resident  with  the  SDF.  An  engineering 
data  archival  facility  will  be  also  required  for  retaining 
history  data  for  the  ground  and  station  operational  data  as 
well  as  design  history  data.  This  archival  facility  could  be 
co-resident  with  the  engineering  analysis  facility. 

All  of  the  computing  facilities  would  need  to  have  interfaces 
with  SSIS  and  TMIS  to  provide  access  to  the  appropriate  data. 

As  the  SSP  goes  thru  the  development  phase,  each  of  the  work 
package  centers  and  prime  contractors  will  have  TMIS 
capabilities  as  well  as  the  other  capabilities  indicated  above. 
As  the  program  evolves  to  a centralized  sustaining  engineering 
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mode,  a transition  should  be  planned  to  migrate  these 
capabilities  to  the  same  location.  It  would  appear  most  cost 
effective  to  do  this  in  conjunction  with  a planned  system 
upgrade  to  eliminate  obsolete  equipment.  This  would  allow 
functional  overlap  which  would  minimize  support  impacts  and  be 
cost  effective.  The  elimination  of  duplicate  computing 
facilities  will  save  substantial  amounts  of  money  - not  only  in 
the  annual  operations  and  maintenance  costs,  but  also  in  the 
replacement/upgrade  costs.  Maintenance  costa  for  computer 
systems  are  approximately  12  percent  of  the  acquisition  costs 
annual.  With  an  industry  standard  upgrade  cycle  of  5-7  years, 
annualized  replacement  costs  are  14  to  20  percent.  Elimination 
of  unnecessary  capabilities  would  thus  result  in  an  annual 
savings  of  25-30  percent  of  the  original  acquisition  cost, 
disregarding  the  operation  cost  which  is  not  insignificant. 

Payload  Processing.  The  prelaunch  integration  and  post  landing 
deintegration  information  systems  support  will  be  provided  by  a 
mix  of  TMIS  and  6DMS.  The  GDMS  utilizes  the  SSE  for 
development  in  software  design  and  implementation,  production, 
training,  networking  and  various  management  tools.  GDMS  unique 
software  will  be  generated  in  ADA  and  will  have  some  limited 
Artificial  Intelligence  (AI)  applications. 

The  GDMS  will  support  procedure  development,  simulations,  real 
time  test  monitor  and  control,  post  test  retrieval  and  will 
include  a record  and  playback  station  for  raw  data  retrieval. 
The  GDMS  will  provide  for  real  time  control  and  monitoring 
during  rack  to  Space  Station  interface  testing  with  GDMS 
providing  a SS  interface  simulation.  Current  program  planning 
calls  for  GDMS  to  interface  with  TMIS  at  KSC  through  the  KSC 
Office  Automation  System.  Data  that  will  be  required  to  pass 
the  interface  include: 
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o Problem  Reporting/Repair  Paper 
o Planning  Data /Performance  Reporting 
o Change  Paper 
o Modification  Data 
o Configuration  Data  and  Reports 
o Manifesting  & Scheduling  Data 
o Test  Requirements 
o Engineering  Data 

With  a 6DMS  & TMIS  interface,  the  information  systems  support 
is  relatively  insensitive  to  the  location  of  initial  rack 
integration/deintegration  (see  prelaunch  options)  but  some 
impact  may  be  experienced  at  the  interface  and  the  resultant 
intercenter  communications . It  is  imperative  that  the  program 
reevaluate  the  6DMS/KSC  OAS/TMIS  interface  for  sizing  and 
throughput.  There  also  is  a requirement  for  a GDMS  and  STDN 
interface  to  support  prelaunch  verification,  and  GDMS  and 
Logistics  System  interface  to  support  prelaunch  activities. 

6.1.3  Support  Systems 

Operations.  The  information  systems  supporting  the  SSP  will 
have  hardware  and  system  software  distributed  at  remote  sites 
which  should  be  operated  and  maintained  by  the  local 
institution.  The  application  software  on  these  systems  should, 
in  many  cases,  be  common.  This  common  software  should  be 
centrally  maintained  and  configuration  managed  to  assure 
continuous  system  compatibility. 

Operations  philosophy  will  vary  between  field  installations, 
but  support  activity  parameters  should  be  established  by  SSP 
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policies  and  standards.  With  an  operational  system  that  will 
be  heavily  dependent  upon  the  computer  system a,  data  bases  and 
the  communication  networks,  it  is  highly  recounended  that 
operational  philosophy  and  system  design  (including  facilities) 
should  be  oriented  toward  a high  percentage  of  system 
availability  rather  than  the  current  attitude  of  a management 
information  system  being  non-mandatory,  therefore,  reliability 
is  not  an  issue.  In  order  to  support  the  Space  Station  on  a 
reliable  basis,  all  systems  must  be  user  supportive. 

Disaster  plans  should  be  developed  which  include  utilization  of 
other  program  resources  to  transfer  critical  functions  to 
another  similar  facility  in  order  to  maintain  the  support 
required  to  meet  scheduled  launches  or  provide  real-time 
support  to  the  Space  Station.  An  overall  analysis  of  SSIS 
elements  should  be  done  while  the  systems  are  being  designed 
and  developed  to  identify  critical  functions  and  where  they 
could  be  transported  to.  An  operations  plan  cannot  correct  for 
lack  of  design  planning.  This  level  of  planning  must  come  from 
the  Program  Office  since  it  must,  by  nature,  cross  program 
elements  and  centers. 

Capability  to  share  resources  should  also  be  provided  in  system 
design.  If  a function  can  be  moved  in  case  of  a disaster,  it 
should  be  able  to  move  if  a particular  facility  is 
over-utilized  while  another  is  underutilized.  Rather  than 
buying  more  capability,  the  functions  could  be  redistributed  to 
effect  a more  even  workload,  This  type  of  decision  could  only 
be  effective  if  there  is  centralized  management  and  funding 
control  for  ICS. 

Another  aspect  of  operations  to  be  considered  is  the  provision 
for  a centralized  care  center/control  center  to  be  established. 
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This  center  would  be  responsible  for  being  a single  point  for 
user's  to  contact  for  problems  on  the  network  and  a centralized 
decision-making  point  for  resource  utilization  of  ICS  systems 
which  would  be  for  the  support  of  the  SSP  and  not  based  on 
institutional  preferences. 

Facilities.  Some  Space  Station  Program  support  shall  be 
provided  through  institutional  capabilities  at  various  NASA 
centers.  In  other  cases,  facilities  will  be  retrofitted  to 
house  information  systems  or  new  facilities  will  be 
constructed.  Where  facilities  are  generated  for  Information 
Systems  support  the  following  items  are  recommended  as  a 
minimum  set  of  generic  requirements: 

a . Equipment  Accommodations : 

o Maintenance  Laboratories 
o Engineering  Laboratories 
o Raised  Floor  Space 

o Printer  Area  (Separate  from  computer  operations) 
o Control  Center  (Separate  from  computer  operations) 
o Spare  Parts  Storage  & Supplies  Area 
o Minimum  Security  Access  Control 
o Ha Ion  Fire  Suppression 
o Emergency  Power  Shutdown  Switch 
o Conditioned  Power  & Emergency  Switch-over 
o Individual  Air  Conditioning  Units 
o Water  Detection  System  & Controls 
o Computerized  Monitor  Interface 
o Library  Space 
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o Lighting  (Controlled  and  Emergency) 

o Communications  Areas  (Including  Common  Carrier 
Interface  Areas) 

o Cooling  Water  Supply 

o Disaster  Control  Equipment 

b*  Personnel  Accommodations: 

o Office  Areas 

o Comfort  Air 

o Conditioned  Power 

o Break  Area 

o Personal  Computer  Communications 
o Fire  Protection 
o Emergency  & Controlled  Lighting 
o Building  Access  Control 
o Phones 

o Paging  & Area  Warning 
o Conference  Areas 
o Video  Distribution  Equipment 
c . Required  Equipment : 

o Main  Frame(s)  and  Peripherals 

* 

o Back  Up  Main  Frame(s) 
o Back  Up  Power  Equipment 
o Personal  Computers 
o Halon  & Halon  Control  Equipment 

o Communication  Transmission  & Receiving  Equipment 
o Break  Out  Racks  & Trouble  Shooting  Equipment 
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o Acoustical  Control  Apparatus 
o Trouble  Shooting  Communications 
o Fire  Proof  & Static  Resistant  Floor  Covering 
o Master  Consoles  - Computer  Control  and  Communications 
o Spare  Parts  & Racks 

o Disaster  Recovery  Library  (Separate  from  Computer 
Facility) 

It  is  recommended  that  a uniform  set  of  criteria  be  developed 
which  all  key  information  system  facilities  supporting  the  SSP 
would  have  to  meet.  This  would  preclude  the  problem  of  a key 
system  not  supporting  because  of  the  routine  and  mundane 
facility  issues.  A reliable  computer  system  coupled  with 
inadequate  facility  support  will  result  in  poor  computer 
support . 

6.1.4  Management  Structure 

The  management  structure  of  information  and  communications 
systems  is  divided  basically  into  the  strategic,  tactical  and 
execution  levels  as  depicted  in  Figure  6-1. 

Strategic  Management.  The  strategic  management  of 
communication  and  information  systems  consists  of  the  long 
range  planning— primarily  in  the  five  to  thirty  year  range. 
Strategic  planning  of  this  range  is  important  to  assure  that 
long  range  goals  and  policy  are  set  far  enough  ahead  to  assure 
that  budgetary  planning  can  be  done  to  promote  smooth 
transitions  required  by  evolutionary  upgrades  in  both  hardware 
and  software. 

Historically  the  mission  support  systems  have  been  implemented 
early  to  support  a program  and  become  obsolete  during  the 
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support  of  the  program.  This  could  be  tolerated  in  short  range 
programs  such  as  Apollo.  As  we  enter  the  Space  Station  Program 
which  is  planned  for  a minimum  of  thirty  years,  the  life  cycle 
of  computer  systems  must  be  considered  as  discussed  in  the 
Growth  and  Evolution  Section.  Budgetary  planning  for  the 
associated  upgrades  is  of  utmost  importance  and  should  be  done 
on  an  agency-wide  basis. 

Another  area  which  involves  strategic  planning  for 
communication  and  information  systems  is  the  establishment  of 
policy  regarding  standards— not  what  the  specific  standards 
should  be,  but  what  general  class  of  standards  should  exist  and 
the  scope  of  activity  to  which  they  should  apply.  This  is 
important  in  assuring  all  systems  can  participate  in  evolution 
plans  for  future  hardware  changes  and  development  of  future 
interfaces • 

The  final  area  of  strategic  planning  for  communications  and 
information  systems  is  the  area  of  operations  policy.  The 
strategic  management  level  should  set  policy  guidelines  for 
information/communication  security,  data  integrity  and  overall 
commonality  of  systems. 

Because  of  the  scope  of  the  activities  of  strategic  management 
of  communication  and  information  systems,  this  management  would 
best  be  placed  at  as  high  a level  as  possible.  Since  many 
systems  which  support  Space  Station  also  support  other 
programs,  this  management  could  best  be  effected  on  an 
Agency-wide  basis  rather  than  a program-wide  basis.  Realizing 
the  current  structure  of  the  agency  places  funding  control  at 
the  program  level , the  only  effective  place  for  this  to  be 
during  the  development  phase  is  at  the  Level  A program  level. 

As  the  transition  to  operations  occurs  and  associated  funding 
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shifts , this  function  should  shift  with  the  funding  to  the 
operations  organization,  which  then  places  it  in  a position  to 
assure  all  operational  programs  are  subject  to  the  same 
policies. 

Tactical  Management.  The  tactical  management  of  communications 
and  information  systems  consists  of  the  intermediate  range 
planning — primarily  in  the  one  to  seven  year  range.  This 
management  level  will  be  responding  to  the  foundation  of  long 
range  planning  provided  from  the  strategic  level  to  assure  that 
plans  for  evolution  and  growth  become  more  definitized  and  that 
budget  requirements  become  more  specific.  This  level  of 
management  is  also  responsible  for  the  specification  of  the 
specific  standards  to  be  applied  across  multiple  systems  as 
well  as  assuring  the  standards  are  implemented  at  the  execution 
level.  Implementation  planning  for  the  operations  policies 
established  by  the  strategic  level  would  also  be  performed  at 
the  tactical  level. 

An  important  function  of  Tactical  Management  is  the  provision 
for  data  base  planning  across  the  program.  This  would  be  done 
by  a Data  Strategist.  The  Data  Strategist  is  a top-level 
data-base  planner  who  should  create  a program-wide  plan  for 
what  data  resources  are  needed.  This  plan  should  also  address 
what  data  bases  should  exist  at  different  sites  and  to  what 
extent  they  share  the  same  data  structures.  The  Data 
Strategist  would  assure  that  a common  Data  Dictionary  would  be 
maintained  across  the  program  to  assure  any  future  integration 
of  data  bases  could  be  effected  with  minimum  impacts.  Because 
the  future  evolution  of  data  bases  is  heavily  dependent  on 
activities  during  the  development  program,  the  Data  Strategist 
function  must  be  put  in  place  now  with  strong  top  program 
management  support  to  assure  his  affectiveness  across  the  work 
packages . 
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The  tactical  management  would  also  be  responsible  for 
determining  the  functional  distribution  of  responsibilities 
among  the  institutional  and  center  program  support  facilities 
when  new  capabilities  are  required.  This  will  assure  duplicate 
non-common  capabilities  will  not  be  generated. 

Another  function  which  would  co-reside  with  the  tactical 
function  but  is  more  execution  by  nature  is  the  management  of 
combined  acquisitions.  In  order  to  assure  compatibility 
between  systems  and  to  get  better  leverage  in  the  procurement 
process,  combined  acquisitions  should  be  done  whenever  possible 
to  implement  the  evolutionary  upgrades  of  the  hardware  and  soft 
ware.  Because  these  acquisitions  would  involve  multiple 
centers,  it  is  recommended  that  these  acquisitions  be  managed 
from  the  program  level . 

Execution  Management.  The  execution  management  of 
communications  and  information  systems  consists  of  near  term 
planning  (0-3  years)  and  operations  implementation.  It  will 
include  the  implementation  of  the  evolution  plans  thru  actual 
hardware  acquisition  and  installation.  They  are  also 
responsible  for  the  operations  and  maintenance  of  the  systems 
once  installed  as  specified  in  the  Operations  section. 


Execution  level  management  is  decentralized  and  resides  with 
the  hardware  systems  whether  they  are  institutional  or  program 
unique  resources.  An  oversight  function  performed  by  a 
contractor  such  as  the  Program  Support  Contractor  will  assure 
policies  and  standards  established  at  the  tactical  level  are 
being  adhered  to.  This  is  required  because  of  the  diverse 
locations  involved  and  the  reporting  hierarchy  for  the  many 
organizations  involved. 
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GUIDELINES  AND  DEFINITIONS 


1.  Single  authority  source  for  all  safety  for  both  NSTS  and 
SS. 


2.  SS  and  NSTS  will  only  document  and  verify  user  requirements 
associated  with  interfaces  (physical  and  operational)  and 
safety  for  flight  and  ground  operations. 


3.  Telescience  concept  to  be  implemented  by  NASA  such  that 
user  support  to  NASA  directed  test  operations  can  be 
provided,  where  appropriate,  using  Telescience  network. 


4.  All  NSTS  involved  operations  to  be  controlled  by  NASA  NSTS. 


5.  All  NASA  SS  facility  simulators  to  user  hardware /software 
interface  testing  to  be  controlled  by  NASA. 


6.  SS  logistics  function  treated  as  another  user  for 
preflight /postflight  operations. 


7.  Fluid  carrier,  and  propellant  carrier  processed  only  at 
launch  site  (KSC). 


8.  ELV  processing,  relative  to  payloads,  is  part  of  total 
ground  processing  operations. 


9.  Space  Station  system  racks  for  supply,  replacement,  spares, 
modification  kits,  etc.,  will  be  processed  in  accordance 
with  logistics  processing  including  prepacked  lockers 
and/or  racks,  etc.,  as  may  be  required  to  maintain  flow  and 
verification  activities. 
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. Racks  processing  hardware,  procedures,  documentation, 
handling  gear,  and  installation  kits  will  have  reached  a 
mature  point  by  time  of  start  of  IOC  phase,  thereby 
providing  for  generic  procedures  and  minimum  changes  to 
both  payload  and  system  users. 


11.  A processing  flow  providing  for  minimum  time  for  hardware 
and  personnel  at  locations  away  from  the  principal 
investigator/developer  is  required  by  users  and  highly 
desirable  to  NASA  to  encourage  and  facilitate  Space  Station 
user  developments . 


12.  A flexible  flow  enabling  changeout  of  experiment  elements, 
additions,  deletions,  change  in  manifest,  early  and  late 
access  is  essential  for  operations  flexibility,  management, 
and  user  friendly  considerations. 
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DEFINITIONS : 


Payload  Integration  Organization  (PIO) 


The  PIO  will  perform  the  functions  required  to  integrate, 
verify,  and  certify  to  Space  Station  (SS)  and  NSTS  a Space 
Station  Incremental  Mission.  Among  these  functions  are: 

o Provide  interface  to  users  for  requirements, 
verification  operations,  etc. 

o Provide  interface  to  SS  and  NSTS  to  satisfy  their 
requirements  for  the  mission. 


o Responsible  for  development  of  required  documentation 
for  the  mission. 


o Conducts  and  supports  reviews,  meetings,  etc.  required 
to  support  planning  and  implementation  of  the  mission. 


Space  Station  Incremental  Mission  is  defined  as  the  flight  of 
an  NSTS  carrier  to  support  the  Space  Station  (SS).  Mission 
hardware  includes  all  items  going  up  to  the  Space  Station  to 
support  next  configuration  of  the  SS  and  that  hardware  or  other 
items  returned  from  the  SS. 

Science  and  Technology  Center  (S&T  Center) 

The  Science  and  Technology  Center  (S&T)  is  defined  as  that 
location  having  the  unique  expertise  to  support  a particular 
payload  discipline.  For  example  for  Life  Sciences,  this  would 
include  Johnson  Space  Center  for  the  human  elements  and  Ames 
Research  Center  for  nonhuman  (plants,  animals,  cells)  elements. 
For  Materials  Processing  this  would  be  referenced  to  Marshall 
Space  Flight  Center  for  metals  and  inert  substances  and  one  of 
the  life  science  organizations  if  at  a cellular  level;  i.e., 
antibiotics. 

Option  Evaluation  Categories: 

o Flexibility 
o Feasibility 
o User  Friendly 
o Management  Efficiency 
o Cost  Effectiveness 
o Performance 
o Safety 
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APPENDIX  C 


SCORING  CRITERIA  DEFINITION 


1.  FEASIBILITY  - "Doable,"  capable  of  being  carried  out 
completion. 


2.  FLEXIBILITY  - Capable  of  responding  to  new  situations,  i.e. 
Space  Station  growth  and  evolution  to  a new  configuration, 
does  not  (necessarily)  have  to  be  scrapped  or  junked. 


3.  USER  FRIENDLY  - Provides  easy  training  and  use  to  a journey 
level  person  with  average  IQ,  intellect  and  motor  sensory 
skill /perception . 


4.  EFFECTIVENESS: 

a.  Transition  - How  easy  is  it  to  go  from  phase  C/D  to 
Phase  E (Operational)? 

b.  Management  - Does  this  option  lend  itself  to 
"effective"  management  skills,  tools? 

c.  Cost  - What  is  relative  life  cycle  cost  of  one  option 
compared  to  other  options  for  the  function  or 
subfunction? 

d.  Performance  - Is  it  capable  of  doing  the  function  in  a 
timely  and  sufficient  (all  that  is  required)  manner? 


5.  SAFETY  - What  is  the  relative  risk  of  bodily  harm  or 
hardware /software  damage? 


6.  TERMINATION  - Can  this  option  be  terminated/ elimi- 
nated/phased out  without  terminating  the  total 
station/having  cataclysmic  affects: 
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AN  APPROACH  TO  SPACE  STATION  DOCUMENTATION 


S.  Blackmer 


DOCUMENTATION 

A major  function  of  the  PIO  will  be  to  negotiate  and  document 
agreements  with  a wide  range  of  Space  Station  users.  A 
document/data  base  system  should  be  established  to  meet  the 
following  requirements: 

o User  friendly  to  Space  Station  users,  the  Space  Station 
operator,  and  the  STS  operator* 
o Flexible. 

o Complete  (all  necessary  data), 
o Minimum  superfluous  data. 

o Eliminate  need  for  multiple  entry  of  same  data. 

A system  structured  in  a manner  similar  to  that  currently  used 
with  the  STS  but  streamlined  by  incorporating  modern  data  base 
techniques  could  meet  the  above  requirements. 

The  basic  planning  document  in  the  STS  payload  integration 
process  is  the  PIP  (Payload  Integration  Plan).  It  is  a joint 
payload/STS  agreement  and  is  normally  initiated  after  NASA 
Headquarters  has  accepted  the  payload  by  signing  an  STS  form  100. 
Several  PIP  outlines  (blank  books)  have  been  developed  as  guides 
for  the  various  types  of  payloads.  This  allows  minimum  P/L 
interaction  with  the  STS  for  simple  payloads  while  providing  the 
technical  depth  required  for  the  integration  of  complex  payloads. 
Short  paragraphs  and  tables  in  a structured  form  in  the  PIP 
address  all  areas  of  mutual  STS/Payload  concern.  Other 
subsidiary  documents,  where  appropriate,  called  "annexes”  are 
controlled  and  signed  by  managers  at  the  implementation  level. 
This  provides  a mechanization  for  detailed  agreements  with 
working  level  personnel  but  these  detailed  agreements  must  always 
be  within  the  boundaries  prescribed  in  the  PIP.  In  addition 
there  is  an  ICO  defining  in  detail  the  interfaces  specified  in 
the  PIP. 

A negotiated  document/ information  system  conceptually  similar  to 
the  PIP  could  be  developed  for  Space  Station  users.  Management 
of  the  system  would  be  a function  of  the  PIO.  In  this  scenario  a 
Space  Station  "User"  would  be  virtually  any  identifiable  (by  AA) 
entity  or  group  of  entities;  (i.e.  experiment,  rack  or  Space 
Station  element).  Several  top  level  "blank  book"  documents  would 
be  structured  to  simplify  the  documentation  task  for  the  various 
classes  of  "users".  "Annexes",  as  necessary,  would  be  developed 
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between  the  user  and  implementation  level  Space  Station 
personnel.  Dse  of  a single  properly  structured  data  base  for  the 
top  level  document  and  "annexes"  should  preclude  the  problem  of 
multiple  entry  of  the  same  data.  This  data  base  is  then  a basic 
information  tool  in  the  manifesting  process  and  is  used  by  the 
PIO  and  implementing  organizations  as  input  data  for  integrated 
engineering  analysis.  It  is  also  used  for  ground  processing  and 
integrated  flight  documentation.  Having  gathered  the  "user" 
information,  even  in  preliminary  form,  the  PIO  can  serve  as  the 
agent  for  all  Space  Station  users  and  becomes  the  "Payload"  in 
the  STS/Payload  PIP  process.  This  concept  serves  a dual  purpose 
in  that  the  Space  Station  user  has  a single  contact  in  the  Space 
Station  PIP  and  the  Space  Station  appears  as  a single  payload  to 
the  STS. 

Table  1 provides  an  example  of  the  types  of  documents /information 
that  the  PIO  may  need  from  a user.  The  level  of  complexity  may 
be  such  that  only  a brief  paragraph  or  set  of  tables  in  the  top 
level  document  is  required  or  one  or  more  detailed  lower  level 
documents  may  also  be  required.  For  convenience  the  requirements 
are  separated  into  four  categories;  Design,  Verification  and 
Test,  Space  Transportation,  and  Space  Station  Flight  Planning  and 
Implementation.  A brief  description  of  each  listed  document 
follows: 

ICD 

A unique  ICD  for  each  user  based  on  a single  Space  Station  ICD 
specifying  all  standard  Space  Station  services. 

Data  Package 

Specifies  user  mass  properties,  provides  configuration 
drawings,  and  provides  user  physical  function  data. 

Software/Data  System 

Provides  all  necessary  user  information  for  User /Space 
Station  command  and  data  interaction. 

Equipment  Buildup 

Defines  user  equipment  build-up  requirements  for  on-orbit 
configuration. 

Joint  Space  Station/user  Test  Req. 

Defines  interface  tests  for  that  testing  that  can  be 
accomplished  on  the  ground  and  for  that  testing  that  must  be 
deferred  until  on-orbit. 
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Equipment  Assembly  Requirements  (ascent) 

Specifies  any  unique  requirements  while  in  the 
ascent  configuration. 

Equipment  Assembly  Requirements  (return) 

Specifies  any  unique  requirements  while  in  the  return 
configuration . 

Equipment  Dispersal  (post landing) 

Defines  requirements  for  return  of  equipment  to  user  and  any 
special  handling  requirements. 

Flight  Planning 

Defines  flight  activity  requirements  such  as  crew 
operations,  sequence  of  events,  etc. 

Flight  Operation  Support 

Defines  support  operations  such  as  major  operations 
decisions,  user  support  plans,  malfunction  operations,  etc. 

Training 

Defines  training  requirements  and  responsibilities  for 
ground  and  flight  personnel. 

POCC  Interface 

Defines  POCC/Space  Station  control  center  interfaces  and 
operations . 
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TABLE  1 


DESIGN 

VERIFICATION  AND 

PHYSICAL 

INTEGRATION 

SPACE 

TRANSPORTATION 

SPACE  STA- 
TION FLIGHT 
PLANNING  AND 
IMPLEMENTATION 

0 I CD 

0 ANALYTICAL 
<SS  AND  TRANS) 
STRUCTURAL 

0 EQUIP  ASSEM 
REQ  (ASCENT) 

0 FLIGHT 
PLANNING 

0 DATA 
PACKAGE 

THERMAL 

0 EQUIP  ASSEM 
REQ  (RETURN) 

O FLIGHT  OPS 
SUPPORT  REQ 

0 SOFTWARE 
DATA 
SYSTEM 

0 EQUIPMENT 
BUILDUP 
(SS  CONFIG) 

0 JOINT  SS/USER 
TEST 

PREFLIGHT 
ON  ORBIT 

0 EQUIP  DISPERSAL 
(POSTLANDING) 

0 TRAINING 

O POCC 

INTERFACE 

0 SAFETY* 

O SAFETY* 

O SAFETY* 

SAFETY* 

* Safety  is  an  ongoing  consideration  from  design  through  postlanding 
requiring  periodic  reviews  and  approval . 
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A USER'S  PATH  TO  SPACE  STATION 


Dr.  Michael  Wiskerchen,  Jan.  21,  1987 


The  following  discussion  will  follow  through  a scenario  for  a 
typical  solar-terrestrial  investigator  wanting  to  utilize  the 
Space  Station.  It  will  be  assumed  that  the  investigator  will 
be  funded  through  an  organization  like  the  Office  of  Space 
Station  and  Application  (OSSA-Code  E)  for  the  investigation  and 
that  all  elements  of  the  Space  Station  (modules,  platforms, 
etc.  both  U.S.  and  international)  will  be  accessible. 

The  investigator  is  from  Standfud  University  (USA)  and  had 
never  flown  a space-borne  experiment  before.  The  investigator 
is  a member  of  the  International  Solar-Terrestrial  Science 
Society  and  had  heard  about  the  Space  Station  through  that 
organization.  The  investigator's  first  action  is  to  contact 
the  Space  Station  office  in  Washington  (this  would  be  assumed 
because  of  the  Federal  funding)  and  ask  for  the  Space  Station 
science  office  (single  point  contact  office  for  Space  Station 
utilization).  This  utilization  office  should  be  staffed  with 
personnel,  one  of  which  is  assigned  to  the  potential  Space 
Station  user,  who  are  knowledgeable  about  possible  funding 
sources  (NASA,  NSF,  other  federal  agencies,  private  sector, 
international)  for  this  area  of  science  investigation.  This 
utilization  office  will  also  provide  detailed  descriptive 
documentation  on  all  Space  Station  capabilities  and  historical 
documentation  on  present  and  past  usage  of  Space  Station.  All 
of  this  material  should  be  made  available  electronically 
(on-line)  so  that  the  potential  user  may  browse  through  the 
documentation.  The  investigator  then  decides  to  participate 
through  the  NASA  OSSA  route.  The  investigator  may  get  all  of 
the  OSSA  documentation  from  the  on-line  library  or  request  that 
the  Space  Station  Utilization  Office  (SSUO)  assist  in  making 
the  necessary  contacts  in  OSSA.  The  investigator  finds  out 
that  at  OSSA,  Solar-Terrestrial  Division  has  issued  an 
announcement  of  opportunity  (AO)  which  provides  funding  for 
this  area  of  science  research. 

The  investigator  responds  to  the  AO  by  submitting  a proposal 
for  an  investigation  involving  the  building  of  an  instrument 
set  (one  to  be  flown  in  polar  orbit  and  the  other  at  28 
degrees)  and  doing  coordinated  research  with  instrumentation 
provided  by  investigators  from  Japan  and  Europe.  OSSA  receives 
the  proposal  and  has  it  peer-reviewed.  The  peer  review  (based 
solely  on  science  objectives)  is  positive.  Before  the  proposal 
can  be  accepted,  OSSA  must  determine  the  technical,  scheduling, 
and  logistics  aspects  of  the  proposed  investigation  and  whether 
they  can  be  accommodated.  OSSA  contacts  the  SS  Payload  Inte- 
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gration  and  Engineering  Office  (SSPIEO)  for  this  accommodation 
information.  The  SSPIEO  evaluates  resource,  logistics, 
schedules  requirements  and  informs  OSSA  that  it  is  possible  to 
accommodate  the  investigator  with  certain  constraints.  OSSA 
then  notifies  the  investigator  that  the  proposed  investigation 
is  selected  with  certain  specified  constraints.  OSSA,  by 
accepting  the  proposal,  commits  to  funding  the  construction  of 
the  instrumentation,  checkout  and  integration  of  instrumen- 
tation, experiment  operations  (investigator  team),  subsequent 
analysis  of  scientific  data,  archiving  of  scientific  data  as  a 
national  resource,  and  finally  publication  of  science  results. 
To  carry  out  the  above  functions,  OSSA  will  designate  a science 
program  staff  consisting  of  a program  manager  and  scientist  to 
provide  an  interface  point  to  the  investigator  in  each  of  the 
above  OSSA  budgeted  areas. 

Although  during  this  phase  the  SSOO  has  transferred  single 
point  contact  responsibility  to  OSSA,  it  remains  fully  aware  of 
the  disposition  and  activities  of  this  SS  user.  The  SSDO 
should  maintain  an  on-line  data  base  of  all  this  information 
for  future  reference  and  marketing  analysis. 

At  this  phase  of  the  program  the  investigator  begins  con- 
struction of  the  instruments  and  also  begins  detailed  science 
planning  discussions  with  other  investigators  (from  Japan,  and 
Europe)  who  will  be  directly  involved  in  the  investigation. 

Also,  at  this  time,  the  investigator  will  become  a member  of 
the  Space  Station  User  Working  Group  (SSOWG).  Although  OSSA 
will  retain  management  responsibility  for  those  areas  covered 
by  the  OSSA  budget,  the  investigator  will  be  referred  to  the 
SSUO  to  be  guided  on  all  contact  interfaces,  procedures,  and 
responsibilities  associated  with  the  Space  Station. 

The  SSUO  will  define  for  and  inform  the  investigator  about  the 
interfaces  to  the  Space  Station  for  engineering,  operations 
planning  and  scheduling,  and  management  procedures  and  details. 
The  investigator  will  be  directed  to  the  SSPIEO  where  the 
investigation  will  be  assigned  to  a particular  Utilization 
Operations  Segment  (UOS).  The  figure  below  is  an  organizational 
diagram  of  the  utilization  organization. 
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UTILIZATION  ORGANIZATION  CHART 
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The  investigator  will  be  assigned  to  a specific  Utilization 
Operations  Segment  (UOS),  therefore,  being  assigned  a UOS 
manager  and  scientist  and  becoming  a member  of  the  UOS  user 
working  group  with  input  into  the  SSUWG.  The  rights  and 
responsibilities  the  investigator  has  with  the  SSUWG  are  fully 
documented  and  defined*  The  investigator  will  now  be  reporting 
to  two  separate  offices  with  specific  responsibilities  to  each 
but  on  a single  schedule  agreed  to  by  OSSA  and  the  SSUO.  The 
following  list  indicates  some  of  those  responsibilities. 
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1. 

2. 

3. 

4. 

5. 

6. 

7. 


OSSA 

Announcement  of  Opportunity 

Proposal  science  evaluation 

Investigation  selection 

Assign  program  manager  & 
scientist 

Manage  instrument  devel . 

& science  planning 

Deliver  instrument  to  SSUO 

Discipline  science  goals 
presented  to  SSUWG 


8.  Provide  funding  for  user 
participation  to  ops 

9*  Support  Data  acquisition 

10 » Support  analysis 

11 « Support  publication  of 
scientific  results 

12*  Support  archiving  of  data 


13* 


Provide  information  about 
user  activities  to  SSUO 


SSUO 

Resource  envelop  assign 
Technical  assessment 


Assign  SSPIEO  contacts 


UOS  engineering,  science  ■ 
planning,  timelining 

Integration  into  UOS 

Evaluate  resource  alloc, 
against  resource 
envelopes 

Provide  SS  ops  services 


Support  data  acquisition 

Provide  SS  system 
analysis  information 


Support  archiving  of 
system  information 

Update  utilization  data 
base 
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SPACELAB  EXPERIENCES  & SPACE  STATION  DECENTRALIZATION 

B.  P.  Dalton 


Use  of  the  primary  aspects  of  processing  an  experiment  into  a 
configuration  for  flight  in  0-G,  is  the  physical  integration  of 
hardware.  This  applies  to  all  Space  Station  support  elements 
rack,  payload  interface  adaptors,  platforms.  Integration 
associated  activities  must  reflect  a processing  flow  providing 
minimum  time  for  hardware  and  personnel  at  locations  away  from 
the  principle  investigator /hardware  developer  sites  in  order  to 
encourage  and  facilitate  Space  Station  use.  As  with  any  other 
marketable  item  or  service.  Space  Station  must  accommodate,  not 
intimidate  the  user. 

During  the  Spacelab  era,  accommodation  was  not  foremost.  One 
of  the  primary  issues  contributing  to  U.S.  users'  cost  was 
denial  of  use  of  flight  racks  at  the  hardware  development  sites 
(Science  and  Technology,  S&T  Centers)  for  integration  of  flight 
hardware.  In  Spacelab,  this  is  formally  defined  as  a Level  IV 
activity.  This  meant  several  things  to  the  user: 

o No  Spacelab  flight  rack  was  allowed  to  leave  Kennedy 
Space  Center  (KSC)  to  be  sent  to  a U.S.  S&T  Center. 

o All  physical  handling  of  user  experiment  hardware  to 
install  that  hardware  into  a flight  rack  was  done  by 
KSC  personnel*  at  KSC. 

o All  handling/testing  of  hardware,  after  it  was  within 
the  rack  was  limited  to  KSC  personnel. 

o All  procedures  for  handling  hardware  within  the  rack 
were  KSC  procedures. 

o All  problem  reporting  (PR)  on  hardware  was  within  the 
KSC  system. 

At  the  outset  of  STS/Spacelab  activities,  flight  racks  were  to 
have  been  distributed  to  the  NASA  S&T  Centers.  An  eleventh 
hour  mandate  rescinded  this  program  policy.  The  reverse 
decision  went  into  effect  12  months  prior  to  delivery  of 
Spacelab  1 hardware  to  KSC. 

Theoretically,  this  mode  of  operation  was  a cost  savings  to 
NASA  for  the  following  reasons: 

o Logistics  of  distribution  of  racks  would  require 
additional  sets. 


o Distribution  of  racks  would  add  shipping  costs  to  NASA 
KSC  operations. 

o Development  Center  personnel  lacked  qualified,  trained, 
personel  to  handle  flight  hardware. 

Terms  of  rack  and  shipping  costs,  the  above  were  potentially 
true.  NASA  incurred  added  costs  at  the  development  centers 
because  of  this  highly  centralized  mode  of  operation.  The 
development  centers  were: 

o Forced  to  procure  and  integrate  hardware  into  very 
high  fidelity  ground  racks  ($45K/U.S.  constructed 
unit,  $90K/ESA  constructed  unit);  the  units  also  had 
to  withstand  the  rigors  of  functioning  as  shipping 
containment  for  hardware  to  the  launch  site. 

o Required  to  maintain  a cadre  of  personnel  at  the  launch 
site  for  extended  periods  often  in  accordance  with  KSC 
schedules  and  according  to  the  work  pace  of  KSC 
technicians;  i.e.,  12  man-weeks /rack  for  developer  post 
shipment  testing  and  deintegration  of  highly  complex 
hardware  from  a 6SE  rack,  48  man-weeks  support  during 
KSC  integration/test  in  the  flight  rack  configuration, 

8 man-weeks  support  during  stowage  integration. 

The  S&T  Centers  have  provided  for  Spacelab  and  will  provide  for 
Space  Station,  flight  hardware  at  a level  of  complexity  far 
exceeding  that  of  a rack  structure.  These  Centers  operate 
hardware  and  experiment  development  under  rigid  configuration 
control,  perform  all  integration/test  activities  only  to 
approved  procedures  and  require  certification  of  all  "off  the 
shelf  procured  items,"  and  in  fact  will  not  procure  fabrication 
services  unless  there  is  verification  of  an  "in  place"  OA 
program  or  DCAS  on  site  surveillance.  The  developers  maintain 
the  expertise  pool  which  designed  the  hardware  for  0-G 
qualification  and  operation. 

In  addition  to  the  TDY  personnel  support  costs  incurred  during 
Spacelab  ground  operations,  the  inability  to  readily  gain 
access  to  PRs  proved  very  nonproductive  in  terms  of  time 
required  for  corrective  action  and  final  closure  of  paper  work 
prior  to  flight. 

During  the  operational  phase  of  Space  Station,  the  launch  site 
will  be  exceedingly  busy  maintaining  schedules  of  90  and 
eventually  45  days  resupply  with  the  logistics  modules  <LM  and 
ELMs).  The  launch  site  could  readily  become  a "bottle  neck"  if 
hardware  is  not  delivered  in  as  near  launch  readiness  as 
possible.  Users  and  their  representative  hardware  development 
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centers  can  only  deliver  to  that  level  if  racks  are  provided  to 
them  for  integration.  Because  of  their  Spacelab  activities, 
the  S&T  Development  Centers  currently  maintain  ground  support 
equipment  (GSE)  such  as  ground  cooling  carts,  power  carts,  and 
air  flow  carts.  A s implied  Data  Management  System  (DMS ) 
simulator  or  its  specifications  should  also  be  provided  to  the 
Centers.  This  would  allow  them  to  perform  a limited  interface 
verification. 

This  is  not  to  say  that  no  capability  should  exist  for  last 
minute  interface  verification  capability  (as  required)  at  the 
launch  site.  This  capability  must  be  present  for  contingency 
situations;  i.e.,  shipping  damage  for  both  U.S.  and  Inter- 
national Users,  and  to  accommodate  that  user  not  associated 
with  a Development  Center. 

Centralized  integration  is  not  user  friendly,  allows  no  flexi- 
bility, and  while  potentially  cheaper  to  SS  operations,  results 
in  long  term  costs  to  NASA  S&T  Centers  representing  the  world 
of  users. 
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USER  FRIENDLY  MEANINGS 
B.  P.  Dalton 


The  term  "user  friendly"  haa  been  oft  repeated  since  the 
inception  of  the  Space  Station  Operations  Task  Force.  One  of 
the  initial  activities  of  the  Pre/Post  Flight  Operations  sub- 
panel  was  to  define  this  term  on  the  basis  of  our  individual 
experiences  from  pre/post  flight  operations  during  STS  missions 
and  to  poll  members  of  the  STS  user  community  for  their  defini- 
tions. 

It  was  felt  that  the  Space  Station  Operations  organization,  in 
its  approach  to  providing  "user  Friendliness"  must  accommodate 
the  existing  user  organization  relationships,  not  break  them. 
Users  were  defined  to  include: 

o An  experimenter,  whether  science,  technology,  or 
commercial  oriented,  i.e.,  the  customers  of  Space 
Station . 

o An  entity  (crew  person  or  robotic)  that  works  on  or 
from  the  Space  Station  to  function  an  experiment,  to 
implement  the  manufacturing  process  or  to  service  the 
elements  on  board. 

o The  developer,  builder,  or  assembler  of  all  elements 
incorporated  into  Space  Station  ranging  from  large 
support  structures  through  rack  level  entities. 

o To  the  Space  Station  Program,  this  is  anyone  using 
the  Space  Station  elements  as  a test  facility  whether 
launched  via  the  NSTS  or  any  other  mode. 

o To  the  Kennedy  Space  Center  Launch  Site  support 
operation,  the  user  is  any  element  passing  through 
KSC/Dryden  and  requiring  pre/post  launch  support. 

The  "user  friendly”  scope  of  activities  includes  operations 
leading  up  to  and  including  pre/post  flight  integration,  test, 
and  distribution  along  with  the  associated  user  personnel 
services.  This  includes  the  provided: 

Hardware,  i.e.,  GSE  simulators  and  flight  interfaces 

Facilities,  both  on  and  off  line 

Ground  systems 

Procedures  and  documentation. 
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The  requirements  specified  by  users  in  functioning  of  the  above 
included: 

o Easy  to  use  which  equates  to: 

- Predictable  operation  for  the  user;  when  you  do 
the  same  thing  again,  you  get  the  same  result. 

- No  lies  or  misleading;  what  you  are  asked  to  do 
will  achieve  the  use  desired  and  expected  result. 

- No  hiding  of  significant  requirements  or  neglect 
to  tell 

- Assistance  easily  available  and  applicable  to  the 
situation 

- Assistance  is  given  at  the  level  needed. 

o Easy  to  adapt  to  an  interface  with  hardware,  software, 
and  people.  The  means  of  accomplishment  are  through: 

- One  person/organization  identified  to  support  the 
user  from  the  point  of  manifest  acceptance  through 
final  post  flight  product  delivery  whether  that 
product  is  in  the  form  of  transmitted  data, 
specimen/ sample,  or  hardware. 

- One  time  information  input  is  used  to  serve  multiple 
documentation  sources. 

- Minimization  of  documentation  and  resources  required 
in  terms  of  meetings /review  support,  time,  and 
funding . 

- Flexibility  in  terms  of  schedules  for 
hardware/ software  changes.  This  also  implies  an 
output  of  timely  decisions. 

- Self  training  available  to  show  user  how  to  use  the 
system  ( whatever  it  may  be ) . 

- Quick  look  availability  of  data/results. 

Transparent  operating  system. 

The  last  three  above  items  are  particularly  applicable  to  data 
handling  systems  incorporated  for  pre/post  flight  test,  inflight 
and  post  flight  data  and  analysis. 
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The  second  category,  personnel  accommodations,  are  applications 
of  "user  likes”  which  may  assure  a feeling  of  belonging  and 
identification  with  the  Space  Station  program.  These  were 
identified  as: 

o Providing  offline  areas  for  user  work  under  user 
control . 

o Eliminating/easing  badging  procedures.  Considerations 
included: 

- No  badge  to  get  to  buildings 

- Badges /authorization  good  for  all  NASA  STS  Centers 

- If  badging  at  gate  cannot  be  eliminated,  provide  a 
system  that  gets  badge  to  user  at  his  home  location 
before  traveling  (potentially  telemail  authorization) 

- Provide  Shuttle  Bus  pickup /delivery  of  user  person- 
nel to/from  motels  on  fixed  schedule  and  schedule 
contingencies . 

- Provide  beepers  as  an  intercom  from  work  area  to 
office  area  so  user  may  be  easily  located/warned. 

Input  Sources: 

H.  Rushing  (MSFC  KSC  Resident)  representing: 

ESA  Herman  Kuaschoid  D-l,  D-2 
PI  Scientist  Marsha  Torr  (Memo  Attachment) 

Payload  Specialist  Sam  Durrane,  ASTRO,  John  Hopkins  0. 
Payload  Specialist  David  Bartoz,  NRL 

Japanese  SL  participants,  N.  Kawashima  (Memo  Attachment) 

D.  Suddeth  (6SFC ) 
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October  31,  1986 


From:  MTORR 

To:  HRUSHING 

CC:  MTORR 

Sub j : KSC-ACTIVITIES 

HALLEY, 

We  spent  some  time  yesterday  considering  the  "user-friendly" 
aspects  of  the  KSC  processing.  When  trying  to  define 
"user-friendly"  we  found  that  we  automatically  tried  to  think 
of  problem  areas  that  we  had  encountered  and  what  would  need  to 

be  done  to  improve  or  remove  these.  We  could  not  come  up  with 

very  many,  which  must  mean  that  KSC  is  fairly  user-friendly 
already.  Here  are  our  thoughts  so  far: 

1 . Terminology 

After  some  thought,  we  could  not  come  up  with  an  improvement  on 
the  term  "user-friendly",  so  suggest  that  you  stick  with  it. 

2.  General  KSC  Activities 

What  would  be  very  useful  would  be  a booklet  in  simple  layman 
terms  (NOT  NASA  JARGON 111)  which  tells  each  user  group  what 
will  be  expected  of  them  and  walks  them  through  each  stage  of 
the  processing  at  KSC.  This  should  be  brief  and  simple.  . . at 

the  grade  10  level  ...  and  should  not  read  like  NHB  5300!  It 

should  refer  to  the  formal  documents  but  be  clear  and  readable. 

One  of  my  engineers  suggests  that  it  would  be  useful  to  have  a 
KSC  coordinator  assigned  to  each  user  group.  . . one 
coordinator  could  handle  a few  groups,  and  would  act  as  the 
general  interface /tour  guide.  This  needs  to  be  someone  who 
knows  the  system  well,  where  to  find  things,  what  needs  to  be 
done  next,  who  should  be  contacted  for  what  . . . not  an 
engineer  who  is  involved  with  other  tasks. 

3 . Shipping /Receiving 

The  booklet  described  above  should  include  illustrations  on  how 
to  mark  and  label  equipment,  who  to  talk  to  regarding  shipping, 
etc. 

The  only  major  problem  that  we  encountered  in  the 
shipping/receiving  area  was  the  following:  The  KSC  areas  where 

a user  may  be  busy  at  any  one  time  cover  a very  large  space. 

We  were  most  anxious  to  be  present  at  the  off-loading  of  our 
equipment  at  the  time  of  our  last  shipment  to  KSC.  My 
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engineers  made  efforts  to  be  available  and  were  waiting  to  be 
notified.  They  were  in  one  of  the  KSC  engineer's  offices  at 
the  time  that  the  truck  arrived.  However,  the  buildings  are 
large  enough  that  no  one  had  the  time  to  find  them.  As  a 
result  our  computer  was  damaged  and  is  still  sick. 

SUGGESTION : Check  out  a beeper  to  the  lead  engineer  of  each 

user  group  so  that  they  can  always  be  reached. 

4.  Off-line  Checkout 

Problems  here  seem  to  be  pile-up  in  the  off-line  user  space. 
Since  space  will  always  be  limited  the  only  solution  seems  to 
be  that  each  group  needs  to  be  clearly  notified,  in  advance, 
of  how  long  and  when  they  can  occupy  the  area. 

"User-friendly”  seems  to  boil  down  to  knowing  clearly  what  is 
to  be  done. 

5 . Level  4/3  etc. 

Basically  the  system  as  it  stands  works  well.  The  only  problem 
that  we  have  encountered  turned  out  to  have  a major  impact  on 
us.  During  one  of  the  integration  tests,  we  found  a problem  in 
our  data  stream.  The  individual  with  whom  we  had  to  interface 
in  this  area  insisted  the  problem  was  ours  and  would  not 
investigate  it  further.  As  the  problem  had  only  occurred  in 
the  one  test  and  not  in  the  others  it  was  eventually  abandoned. 
It  turned  out  that  this  was  the  HRM  channel  7 problem  and  as  a 
very  significant  portion  of  the  flight  data  was  taken  in  this 
mode,  our  flight  data  was  seriously  marred  by  sync  losses.  A 
simple  review  should  have  brought  to  light  that  this  was  the 
only  time  that  a test  was  run  in  this  mode,  and  the  HRM  problem 
would  have  been  flagged  in  advance. 

SUGGESTION : The  default  mode  should  not  be  to  make  a user 

engineer  feel  that  every  problem  is  his  until  he  can  prove 
otherwise.  He  just  does  not  have  enough  insight  into  the 
overall  system  to  prove  otherwise.  A higher  individual (s) 
should  review  all  such  problems  and  no  individual  should  be 
able  to  resist /discourage  further  investigation  of  a problem. 

6 . Maintenance /Handling 

The  only  relatively  high  time  consuming  activities  here  tend  to 
be  in  areas  of  safety  and  I don't  see  a way  to  avoid  them. 

Clear  details  of  what  the  user  will  have  to  do  to,  for  example, 
run  a GN2  purge  to  his  instrument  would  be  useful  . . . rather 
than  the  "tell  us  what  you  want  to  do  and  we  will  tell  you  if 
you  can  do  it"  series  of  iterations,  through  multiple  Centers. 
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7.  Procedure  Development 


All  we  can  think  of  here  is  electronic  exchange  of  documents. 

Let  me  know  if  any  of  this  is  useful,  or  if  we  can  expand  it  in 
any  way. 

Regards , 

Marsha  Torr 
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(User  friendly  comments  from  Japanese  who  have  participated 
flown  on  S/L  and  are  working  on  other  missions) 

December  1,  1986 

Dear  Haley, 

I am  not  sure  whether  we  have  fully  understood  "USER  FRIENDLY" 
but  if  it  is  ok  to  write  the  impression  of  KSC  support  for  our 
activity,  it  is  as  follows: 

We  started  our  activity  from  the  beginning  of  1982.  We 
had  had  no  experience  of  activity  at  KSC  before.  We  felt 
a little  uneasiness  at  the  beginning  and  were  a little 
frightened  by  the  strictness  of  the  entrance  to  the  high 
bay  area  and  the  quality  control. 

The  uneasiness  soon  melted  away  when  we  found  that 
everything  went  smoothly  if  we  went  to  your  office  and 
asked  you  and  Dave  Jex  what  we  needed.  Since  then  we  have 
not  had  any  trouble  nor  felt  inconvenience  during  numerous 
activities  of  SEPAC  in  KSC. 

Moreover,  we  must  express  kind  cooperation  of  experiment 
support  group  people.  They  solved  all.  Moreover,  we  must 
express  our  gratitude  to  kind  cooperation  of  difficult 
interface  problems  rather  smoothly.  We  felt  that  each  of 
those  people  had  very  friendly  personality  and  only  such 
people  might  have  been  selected  for  the  job. 

One  example  is  that  about  a week  before  the  start  of 
activity,  we  sent  a fax  or  telemail  to  you  a list  of  GSEs 
to  be  used  for  the  coming  activity.  We  were  very  much 
impressed  when  we  found  those  GSEs  in  the  room  assigned 
for  our  activity. 

Another  is  that  we  had  long  depended  to  our  transportation 
agency  too  much  and  since  they  are  not  used  to  KSC  system 
we  had  much  trouble  in  the  transportation.  In  the  last 
transportation  of  a part  of  our  GSE  to  Japan,  I asked  you 
to  send  it  to  Japan  relying  much  on  you  and  KSC  transpor- 
tation system  and  we  have  found  that  it  is  much  simpler 
and  goes  smoothly. 

In  parallel  to  SL-1  activity,  we  had  a rocket  campaign  as 
a joint  experiment  with  Stanford  Univ  and  USU  using  NASA 
sounding  rocket.  There  we  experienced  inconvenience  which 
cannot  be  compared  with  activity  in  KSC.  The  system  at 


D-19 


KSC  are  well  organized  and  we  can  find  rather  easily  the 
right  person  for  a problem. 

In  our  future  activity  of  ATLAS,  we  hope  that  we  can  find 
you  or  the  equivalent  person  at  KSC. 

I hope  that  the  above  is  the  one  what  you  requested  us. 

Regards , 

Nobuki 
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February  21,  1987 
SS-OTF 

TO:  SS-OTF/Chairman,  Ground  Operations,  Panel  2 

FROM:  SS-OTF/Pre/Post  Launch,  Panel  2 

SUBJECT:  Minutes  of  MSFC  Presentation  to  the  SSOTF 


On  February  9,  1987,  the  MSFC  presented  a ground  verification 
and  processing  briefing  to  the  SSOTF  at  KSC.  Present  from  the 
MSFC  Space  Station  Program  Office  were  Messers  Axel  Roth,  Tom 
Dellinger  and  Bill  Bowen. 

A few  opening  remarks  were  made  by  Axel  mainly  to  the  effect 
that  the  presentation  would  be  keyed  to  the  MSFC  approach  for 
the  phase  C/D  initial  station  assembly  flights.  He  commented 
that  MSFC  has  not  as  yet  done  much  work  in  regards  to  the 
mature  ops  period,  but  that  they  would  be  willing  to  share 
their  thoughts  on  it  with  the  panel. 

Following  Axel's  remarks,  Tom  Dellinger  presented  the  MSFC 
Space  Station  approach  for  prelaunch  verification  and  pro- 
cessing. Mr.  Del linger '8  presentation  is  attached.  The 
approach  as  presented  and  discussed  is  not  a pure  "ship  and 
shoot"  but  one  that  recognizes  that  some  testing  may  or  will 
be  required  at  the  launch  site,  but  that  the  goal  will  be  to 
reduce  it  to  the  minimum  consistent  with  the  program  require- 
ments. The  presentation  was  concluded  with  a general 
discussion  of  various  ways  processing  could  be  accomplished 
during  the  mature  ops  period. 


James  Moore 


cc  • 

MSFC/KA61/A.  Roth 
MSFC/KA51/T.  Dellinger 
MSFC/DA31/B.  Bowen 
SS-OTF/C.  Mars 
SS-OTF/L.  Wells 
SS-OTF/ J.  Mizell 
SS-OTF/G.  Parker 
SS-OTF/K.  Kersey 
SS-OTF/E.  Nelson 
SS-OTF/J . Anderson 
SS-OTF/ J.  Kelley 
SS-OTF /D.  Bohlmann 
SS-OTF/J.  McBrearty 
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CONCEPT  FOR  SPACE  STATION  OPERATIONS 


Eugene  Nelson 


INTRODUCTION/BACKGROUND 


The  Space  Station  will  be  the  first  long  term  sustaining 
operations  managed  by  NASA.  Since  its  inception,  NASA  has 
functioned  as  an  R&D  organization.  This  R&O  management 
implementation  is  evident  in  the  decentralized  multi-center 
management  structure  and  by  the  very  nature  of  its  personnel 
complement  and  their  work  environment.  Personnel  are  hired  by 
NASA  for  their  specific  expertise.  Understandably,  engineering 
and  scientific  degrees  are  the  predominant  salary  winners  even 
though  those  salaries  may  not  be  comparable  to  industry. 
Regardless  of  salary,  personnel  maintain  an  intrinsic  identity 
with  NASA's  leadership  in  technology  and  are  attracted  and 
retained  because  of  the  academic  atmosphere,  the  intellectual 
freedom,  and  the  ability  to  work  at  a pace  commensurate  with 
goals  of  excellence  and  creativity.  As  a result,  NASA  has 
functioned  well  as  an  R&D  organization  and  has  contributed 
extensively  in  placing  the  U.S.  in  a role  of  leadership  in 
science  and  technology.  Indeed,  these  characteristics  observed 
in  the  NASA  structure,  parallel  those  identified  by 
J.  L.  Hunsucker,  Ph.D.,  University  of  Houston,  in  his 
presentation  to  the  Space  Station  Operations  Task  Force  (see 
attachment ) . 

Initially,  the  Space  Transportation  System  (STS)  was  also 
perceived  to  evolve  into  a routine  operation,  similar  to  that 
of  an  airline  firm.  Because  of  inherent  problems  and  the 
complexity  of  the  vehicle,  that  goal  was  never  reached. 

Historically  when  the  manned  Centers  are  assigned  a new 
program,  the  Centers  form  Program  Offices  which  respond  and 
are  under  the  direction  of  the  main  Program  Office  at  NASA 
Headquarters.  During  the  STS/Spacelab  era,  this  approach  was 
utilized.  Each  mission  had  a designated  payload  manager, 
whether  payloads  consisted  of  experiments  in  the  orbiter 
middeck  lockers,  pallets,  spacelabs,  or  any  combination  of  the 
preceding.  With  the  exception  of  the  dedicated  life  sciences 
missions  (Spacelab  Life  Sciences  1/2)  managed  by  Johnson  Space 
Center  Projects  Mission  Office,  payloads  have  been  managed  by 
the  Marshall  Space  Flight  Center  Payloads  Project  Office.  The 
Spacelab  Mission  Manager  was  the  single  point  of  control  for 
payload  integration  including  analytical  and  physical  inte- 
gration, for  flight  operations,  and  for  interfacing  to  the  STS. 


D-22 


Within  NASA  centers,  whether  in  the  role  of  mission  management 
or  in  response  to  mission  management  requirements,  documenta- 
tion and  supporting  analyses  for  missions  have  been  performed 
by  matrixed  engineering  or  contractor  support  to  a Project 
Office.  This  type  of  operation  provided  a technique  whereby  an 
R&D  structure  was  maintained  to  support  Project  Offices.  Final 
responsibility  whether  in  the  role  of  support  engineering. 
Mission  Manager,  or  Project  Office  has  been  to  the  respective 
Center  Directors. 

The  Mission  Manager  was  the  single  point  of  control  for  payload 
integration  including  analytical  and  physical  integration  and 
for  flight  operations,  as  germane  to  the  payload.  In  his  role, 
the  STS/Spacelab  Mission  Manager  represented  a Payload 
Integrating  Organization  (PIO)  responsive  to  the  guidelines, 
specifications,  and  requirements  for  STS  and  Panel  2,  in 
assessing  the  pre/post  flight  ground  operations  perceived 
analytical  and  physical  integration  as  the  major  function 
occurring  under  these  operations.  Analytical  integration  was 
perceived  to  apply  to  all  those  activities,  following 
manifesting,  aside  from  actual  hardware  design,  fabrication, 
test,  and  installation  into  flight  structures,  which  implement 
an  experiment  into  a flight  acceptable  configuration, 
operation,  and  execution.  These  are  the  functions  required  to 
integrate,  verify,  and  certify  to  Space  Station  and  the  NSTS, 
an  incremental  mission. 

Among  these  functions  are: 

o Provide  single  point  interface  for  S&T  and/or 
users  for  definition  of  their  requirements, 
verification,  operations,  etc. 

o Provide  single  point  interface  to  SS  and  NSTS  to 
satisfy  their  requirements  for  the  mission 

o Obtain/coordinate  Space  Station  resource 

requirements  and  ground  processing  requirements 
for  payload  elements  from  S&T  Centers  and/or  users 


Because  of  the  continuous  nature  of  Space  Station  operations, 
an  incremental  mission  is  defined  as  culminating  with  the 
flight  of  an  NSTS  carrier  to  support  the  SS  and  its  return  with 
cargo  from  the  SS.  The  incremental  mission  begins  with  the 
start  of  assembly  of  the  manifest  of  mission  cargo  on  ground 
and  on  SS  that  is  to  be  carried  on  that  NSTS  flight  • Mission 
cargo  includes  all  items  going  up  the  SS  to  support  next 
configuration  of  the  SS  and  that  hardware  or  items  returned 
from  the  SS. 
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o Perform  analytical  integration  of  integration 
mission  to  confirm  compatibility  of  payload 
mission  requirements  to  Space  Station  logistics 
carriers,  and  STS  launch  vehicles 

o Develop  required  documentation  for  the  mission 

o Conduct  and  support  reviews,  meetings,  etc.,  required 
to  support  planning  and  implementation  of  the  mission 

o Provide  SS  Program  with  MANAGEMENT  CONTROL  and 

INTEGRATION  for  various  products,  i.e.,  engineering 
analysis  (power,  thermal,  structures,  safety)  needed 
from  experimenters  for  use  by  the  program 

o Development  test  requirements  and  specifications  for 
the  test  integration  Centers(s)  and  monitor  test 
activities. 


The  concept  of  a PIO  was  a natural  evolution  during  Subpanel  2 
option  analyses  as  a result  of  optimizing  "user  friendliness" 
by  minimizing  interfaces.  Additionally,  it  was  felt  that 
interfaces  that  are  utilized  must  embody  the  expertise  and 
knowledge  to  effectively  translate  user  requirements  to 
functional  application  in  flight.  A single  Payload  Integrating 
Organization,  embodying  corporate  knowledge,  was  perceived  as 
the  most  appropriate  entity  to  fulfill  such  a function. 
Simultaneously,  such  an  organization  must  answer  only  to  the 
Space  Station  Program  (or  as  interface  applicable-to  NSTS)  and 
not  be  "performance  diluted"  by  the  parochial  interests  of 
multi-Centers  or  in  competition  with  other  programs  within 
those  centers.  Over  the  life  of  the  Space  Station,  it  is 
anticipated  there  will  be  R&D  efforts  related  to  the  Aerospace 
plane,  manned  lunar  base,  the  manned  Mars  mission  and  others. 
All  of  these  divert  from  a truly  operational  activity. 

CONCEPTS 


Establishment  of  a PIO  for  tactical  and  execution  levels, 
should  be  apart  from  the  Institutional  parameters  of  existing 
Centers  and  should  maintain  a direct  interface  to  the  Associate 
Administrator  for  Space  Station.  Logistics  and  sustaining 
engineering  would  be  active  supporting  subelements  of  the  PIO. 
Their  payload  requirements  would  be  like  that  of  any  other 
user.  Sustaining  engineering  would  provide  configuration 
control  and  be  capable  of  providing  to  PIO  the  particular 
incremental  mission  resource  boundaries:  logistics  would 

interact  very  closely  with  PIO  to  evaluate  resupply/download 
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requirements  relative  to  proposed  experiments.  Support  to 
users  for  experiment  development  would  be  retained  within  the 
Science  and  Technology  Centers  as  an  R&D  effort  or  would  be 
funneled  directly  into  the  PIO  from  the  self -represented  user. 

Implementation  of  the  above  concept  would  be  through  the 
physical  headquarters  of  the  PIO  in  its  own  building  at  some 
site  or  Center.  Other  assemble,  test,  and  control  elements, 
while  potentially  located  on  the  same  center  property  would  be 
managed  and  budgeted  by  the  Space  Station  management.  The  PIO 
should  be  composed  of  two  fundamental  units.  The  first  unit 
would  be  responsible  for  the  operation  and  care  of  Space 
Station  systems  in  flight  and  on  the  ground;  the  second  unit 
would  be  responsible  for  integration  and  operation  of  payloads 
that  utilize  the  Station  as  their  base. 

A further  factor  in  implementing  such  an  organization  is 
staffing  by  both  engineering  support  personnel  and  purely 
operations  personnel.  Currently,  operations  personnel  of  the 
type  envisioned  necessary  for  long  term  Space  Station 
activities  are  not  in  the  forefront  of  hiring  queues.  If  a 
long  term  organization  is  planned  within  the  current  NASA 
structure  and  culture,  the  issue  of  recruitment  and  development 
of  operational  personnel  will  have  to  be  addressed  to  assure 
that  Space  Station  is  a truly  routine  operation  and  not  a 
research  and  development  activity. 

To  compare  the  objective  pre-requisites  for  effective  manage- 
ment approaches  between  R&D  and  Operational  organizations,  the 
only  organization  that  is  relevant  for  the  "Sustaining  Opera- 
tional Era"  of  the  Space  Station  is  an  operational  organization 
set  up  outside  of  the  present  NASA  R&D  structure  that  more 
closely  reflects  the  characteristics  and  capabilities  of  an 
operational  organization. 
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R&D  VS.  OPERATIONAL  MANAGEMENT 


Characteristics 

R&D 

Operational 

Organization  Structure 

Functional 

Hierarchical 

System  Hierarchies 

Expertise 

Position 

Leadership  Behavior 

Delegation 

Participation 

System  Management 

Decentral ized 

Focused  Power 

Performance  Criteria 

Long  Term 

Result  Oriented 

Reward  System 

Intrinsic 

Extrinsic 

Communication  System 

Informal 

Formal 

Information  System 

Open /Shared 

Structured 

Flexibility 

Long  Term 
Commitment 

Structure  Job 
Description 

Work  Environment 

Intel 1.  Freedom 

Target  Oriented 

Cultural  Climate 

Participative 

Competitive 

Political  Climate 

Contest  for 
Expertise 

Contest  for 
Control  of  Power 

TO: 


Charles  B.  Mars /Chairman,  Panel  2 

FROM:  Pre/Post.  Flight  Subpanel,  Panel  2 

SUBJECT:  Minutes  of  January  21,  1987  Briefing  by  Mr.  Ken 

Frost,  Goddard  Space  Flight  Center,  Assoc.  Director 
of  Space  Flight  Center,  Assoc.  Director  of  Space 
and  Earth  Sciences,  for  Space  Station 
Integration/Verification  Issues  for  Users 

Copies  of  briefing  charts  used  by  Dr.  Frost  in  his  presentation 
are  attached. 

The  briefing  began  with  a description  of  a modern  instrument 
(experiment)  design  which  includes  computer  processors  in 
the  flight  package.  These  processors  operate  the  experiment, 
process  and  compact  the  data,  allow  its  reconfiguration,  and 
now  allow  increased  application  of  expert  systems  and  artifi- 
cial intelligence  to  control  the  data-gathering  elements.  The 
experiment  computer  interfaces  by  data  link  with  a sophisti- 
cated ground-based  computer.  The  ground  computer  develops 
uplink  commands,  and  processes  data.  It  can  also  serve  as  a 
simulator  for  the  experiment  data  interface  with  the  Space 
Station  (SS)  Data  Management  System  ( DMS ) . The  point  was 
made  that  while  the  pre/post  doctoral  experimenters  of  today 
are  conversant  with  computer  technology,  by  the  start  of 
operations  of  the  Space  Station,  such  experimenters  would  be 
computer  virtuosos. 

An  extension  of  the  modern  instrument  would  be  two  or  more 
such  instruments  working  together  on  Space  Station  through  the 
extremely  flexible  DMS  communication  link  (See  multi-payload 
chart) . Since  the  DMS  uses  addressed  packets  of  data  and 
commands  circulating  through  its  network,  instead  of  the  old 
preplanned  rigid  frames  of  data,  reconfiguration  of  user  data 
and  instrument  relationships  is  easy. 

Based  on  this  view  of  modern  instrument  a description  of  the 
user ' s view  of  the  Space  Station  DMS  concept  was  provided . The 
DMS  communications  network  would  be  transparent  to  the  user, 
which  would  allow  the  user  to  interact  with  the  experiment  from 
the  ground  in  a straight-forward  manner,  using  his  own  selected 
computer  language.  The  Space  Station  DMS  would  allow  a flow  of 
the  constantly  available  ancillary  data  on  Space  Station  status 
to  be  selected  by  the  experimenter's  flight  computer  for 
insertion  into  its  telemetry  stream  to  ground.  This  identifies 
the  environment  in  which  the  payload  is  operating.  The  DMS 
would  also  include  an  enabling  capability  for  those  few  types 
of  commands  which  have  system  level  impact  on  the  SS  or  other 
users , such  as : 
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payload  power  envelope;  movement  of  large  masses;  and  venting 
of  gasses.  This  would  prevent  damage  to  other  users.  Of  all 
user  commands , only  about  one  percent  would  have  such  impact, 
the  other  commands  could  flow  the  experiment  directly.  The 
briefing  concluded  with  a vigorous  discussion  of  the  role  of 
simulators  (test  beds)  in  the  experiment  design,  development 
and  verification.  Frost  proposed  that  from  the  start  of 
development  of  the  experiment,  simulations  in  the  user  computer 
should  interface  with  Space  Station  simulations  in  a host 
computer.  These  experiment  data-to-DMS  interface  (data  traffic 
and  networking).  These  emulations  would  go  through  an  evolution 
process  from  low  fidelty,  to  high  fidelty,  to  use  of  the  actual 
DMS  hardware.  The  other  mechanical,  thermal  and  safety  veri- 
fications would  take  place  before  launch  in  a one-time  full-up 
test.  This  approach  would  allow  the  user  to  operate/ verify  his 
experiment  remotely,  from  his  own  facility  and  gain  competence 
in  use  of  the  DMS  system.  The  implication  for  the  Space 
Station  program  is  a need  for  simulation  capability  of  the 
user's  complete  communication  link,  before  launch,  through 
simulated  DMS  networks.  This  method  would  support  both 
"Telescience”  and  conventional  control  of  experiments. 

A suggestion  was  made  and  accepted  as  feasible  by  Frost 
indicated  a new  possibility  that  the  final  compatibility 
verification  of  the  Space  Station  data  management  system  with 
an  instrument  that  has  not  yet  been  launched  could  employ  a 
special  ground-to-space  link  to  the  DMS  on  Space  Station  (or 
platforms).  This  would  allow  directly  checking  the  operation 
of  that  instrument  with  the  flight  DMS,  while  the  instrument  is 
still  on  the  Ground.  This  method  would  remove  the  need  to 
provide  any  high  fidelity  ground  simulator  of  the  Space  Station 
DMS  for  checkout  of  payloads  before  launch.  Frost  commented 
that  on  the  "Solar  Maximum  Mission"  spacecraft,  the  only 
successful  prelaunch  checkout  of  the  interactions  of  the 
multiple  instruments  and  the  spacecraft  data  system  was  through 
the  spacecraft  data  system  itself.  A substitute  simulator  was 
impractical . 


Eugene  Nelson 
cc: 

SS-OTF/P.  Lyman 

SS-OTF/C.  Shelley 

600.0/GSFC/K.  Frost 

SS-OTF:GNelson:crb: 853-9917: 2-2-87 

SS-OTF/Official 

SS-OTF/Reading 

SS-OTF/G.  Nelson 

Library 
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FLIGHT  RACK  PROCESS  ANALYSIS 


W.  H.  OYLER 


The  analysis  of  flight  rack  processing  was  performed  to  deter- 
mine the  sensitivity  of  rack  fleet  quantities  to  the  length  of 
the  overall  supply  and  return  cycle  of  Space  Station  experi- 
ments. The  cycle  of  rack  processing  consists  of  (1)  preparing 
the  rack  for  experiment  integration,  (2)  physical  integration  of 
experiments  into  the  flight  rack  and  verifying  ready  for  launch 
processing,  (3)  installation  of  experiment  rack  into  the 
Pressurized  Logistics  Module,  (4)  launch  to  Space  Station,  (5) 
on-orbit  operation,  (6)  return  to  Logistics  Module  and  de-boost 
to  Earth,  (7)  de-integration  and  return  of  flight  rack  to  fleet 
inventory . 

The  overall  cyclical  process  with  representative  timelines  is 
presented  in  attached  figure  (Rack  Stuffing  Off-Site).  Also 
considered  is  the  accumulative  effects  of  multiple  Logistics 
Modules  being  launched  on  90  day  intervals.  The  duration  of 
each  portion  of  the  processing  cycle  will  vary  as  design  and 
operations  planning  matures,  but  the  times  are  representative 
of  present  planning  and  current  flight  experience  with  similar 
hardware . 

The  conclusion  is  that  a minimum  quantity  of  racks  can  be 
accommodated  when  physical  integration  of  experiments  into  the 
flight  rack  begins  within  approximately  7 months  prior  to 
launch.  Based  on  return  from  Station  intervals,  if  a rack  is 
required  for  experiment  integration  between  7 and  10  months 
prior  to  launch,  then  an  additional  rack  is  required  in  the 
overall  fleet  sizing,  assuming  each  concurrent  Logistics  Module 
flight  continues  to  have  a full  complement  of  User  experiment 
racks.  Each  additional  3 month  increment  required  for 
experiment  integration  into  the  flight  rack  would  require  an 
additional  rack  to  be  added  to  the  overall  fleet. 


VERIFICATION  CONSIDERATIONS 


A.  Rack  Mechanical  Interface 

A suitable  method  for  verifying  the  mechanical  interface  of  the 
physical  latch  and  hinge  attachments  of  rack-mounted  Space 
Station  payloads  is  to  use  the  container  in  which  they  are  to 
be  shipped  to  the  launch  point  as  a master  three-dimensional 
structural  interface  gauge.  All  such  shipping  containers  are 
required  to  be  strong  and  rigid.  The  rack  attachment  points  of 
both  the  container  and  rack  normally  must  withstand  all  shipping 
loads  without  shifting.  The  shipping  container  attachment 
points  could  be  designed  to  be  set  in  the  exact  configuration 
that  duplicates  the  attachment  points  on  Space  Station.  All 
electrical  plugs  and  fluid  connections  would  be  duplicated 
also.  If  the  users  rack-mounted  payload  fit  such  a shipping 
container,  for  shipment  to  the  launch  site,  it  would  fit  the 
Space  Station  attachment  points  also.  The  rack  attachment 
points  in  the  logistics  module  would  also  be  required  to  be  in 
the  same  configuration  as  the  attachment  points  on  space 
station. 

B-.  "Telescience"  Remote  Operation  of  Experiments 

A special  aspect  of  prelaunch  ground  checkout  of  the  user's 
experiment  equipment  and  data  systems  is  that  a large 
proportion  of  user  equipment  on  Space  Station  will  be  remotely 
operated  by  users  from  their  own  ground  laboratories.  From 
there,  they  will  use  Earth  links  to  send  uniquely  addressed 
packets  of  commands  to  the  Tracking  and  Data  Relay  Satellite 
System  (TDRSS),  which  will  link  those  data  packets  to  the  Space 
Station  Data  Management  System  (DMS),  which  will  in  turn  link 
the  data  packets  to  their  various  Space  Station-mounted  equip- 
ments. Those  few  user  commands  that  would  have  an  effect  on 
other  parts  of  Space  Station  would  first  be  routed  to  a 
Verification  and  enable  system"  that  is  transparent  to  the 
user.  This  system  would  hold  execution  of  those  commands  until 
it  is  verified  that  their  interactions  are  not  harmful  to  Space 
Station  or  other  users. 

Data  of  all  sorts  from  the  user  equipment  on  Space  Station 
is  returned  back  through  these  same  electronic  links  to  the 
various  users  laboratories  on  the  ground,  where  users  can 
immediately  observe  the  data  and  act  on  it.  The  users  subse- 
quent commands,  sent  directly  to  their  equipment  through  these 
links,  will  change  and  refine  the  data  taking  modes,  change 
pointing  direction,  etc. 


All  of  the  relation  of  users  to  their  experiment  described 
above  is  meant  by  the  term,  "Telescience",  which  is  defined  as: 
"the  direct,  iterative,  and  distributed  interaction  of  remote 
users  with  their  instruments,  data  bases,  specimens,  and  data 
handling  facilities,  especially  when  remote  operations  are 
essential . ” 

Those  Space  Station  users  who  control  their  experiments  with 
such  "Telescience”  data  links  will  desire  to  check  that  data 
link  operation  during  the  final  interface  verification  test. 

A good  verification  of  the  data  link  requires  that  a good 
emulation  of  the  real  Space  Station  DMS  be  available  on  the 
ground.  This  will  demonstrate  that  Space  Station  will  carry 
through  the  user  data  and  commands  intact  and  verify  that  user 
operation  in  "Telescience”  mode  will  work.  It  might  be  pos- 
sible to  use  the  actual  flight  DMS  itself  for  such  operational 
interface  verification. 
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QUICK  USER  ACCESS  TO  SPACE  STATION 
David  H.  Suddeth 


There  are  classes  of  short  term  Space  Station  users  whose 
interface  verification  needs  are  different  from  those  of  the 
major  program  and  facility  users,  who  intend  to  make  a long- 
term time  and  money  investment  in  operations  on  Space  Station. 
The  short-term  users  are  characterized  by  a positive  need  for 
quick  access  to  Space  Station  and  only  a few  months  residence 
on  it.  Their  physical  and  data  interface  verification  needs 
may  be  much  simpler,  and  can  be  met  by  standard  in-process 
tests.  These  users  might  wish  to  test  new  theoretical  concepts 
or  processes  with  some  special  equipment;  test  the  operation  of 
a piece  of  new  equipment;  or  make  new  kinds  of  measurements  on 
a subject.  The  scientific  community  is  especially  desirous  of 
quick  access  to  Space  Station.  They  have  stated  that  desire  in 
the  phrase: 


"QUICK  IS  BEAUTIFUL" 

"Quick  access”  users  would  include:  university  graduate 

students  trying  to  get  thesis  material;  corporations  and 
research  institutions  testing  new  concept  ideas,  and  others. 

This  user  objective  may  best  be  met  by  user  design  of  very 
simple  interfaces  and  ones  that  are  more  under  user  control. 

Many  Space  Station  users  may  not  need  a direct  verification  by 
Space  Station  program  at  its  verification  facility  of  their 
interface  to  the  Space  Station,  because  they  would  not  attach 
directly  to  a standard  Space  Station  interface.  Instead,  they 
would  attach  at  a "subinterface"  to  a larger  element  that  is 
already  on  such  a standard  interface.  However,  the  verifi- 
cation testing  of  user  operation  at  these  subinterfaces  would 
be  appropriately  controlled  by  PIO  for  purposes  of  Space 
Station  safety. 

Examples  of  larger  elements  that  might  have  such  "subinterfaces” 
available  include: 

(a)  Double  racks  "owned"  by  a university  or  corporation 
that  are  intended  to  stay  on  Space  Station  for  a long 
continuing  research  program,  but  has  drawers  or  slots 
available  for  other  users  from  their  justification; 
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(b)  "Multiple  payload  adapters"  (MPA)  attached  at  one 
external  "Station  Interface  Assembly  (SIA)"  port  on  the 
Space  Station  truss.  These  MPA's  are  intended  to  carry 
five  or  more  separate  payloads  that  will  be  attached  at 
the  one  SIA  port.  These  payloads  may  be  interchanged 
individually; 

(c)  A Space  Station-based  SPARTAN,  small  free-flyer  system 
like  those  flown  from  STS.  The  SPARTAN  system  base 
would  permanently  reside  at  an  SIA  as  an  attached 
payload. 

The  SPARTAN  free-flying  vehicles  carrying  small  experiments 
would  leave  the  base  system,  fly  separately  from  Space  Station, 
be  returned  to  their  base  system,  and  be  interchanged  on  the 
base  system  for  other  SPARTAN  vehicles  carrying  new  experiments. 
All  the  "subinterfaces"  in  the  above  examples  would  be  verified 
during  the  buildup  process  and  finally  verified  for  that  user 
by  the  organization  controlling  the  larger  element  attached  to 
Space  Station*  Responsibility  for  physical  verification  of 
those  users  for  the  health  and  safety  of  Space  Station  would 
rest  with  the  larger  element,  with  review  by  the  Space  Station 
PIO.  The  data  those  users  take  may  be  largely  self -recorded 
for  quick  return..  Their  data  link  through  Space  Station  may 
be  small. 


SPACE  STATION  PLATFORMS 


David  H . Suddeth 


The  Space  Station  Program  will  design  and  build  two  large 
unmanned  spacecraft  called  "Platforms”  that  will  carry  experi- 
ment instrument  payloads  in  orbit  separately  from  the  manned 
Space  Station.  The  platforms  may  do  their  work  separately  from 
the  Space  Station.  The  instruments  and  Platform  operating 
systems  will  be  in  modules  that  have  standardized  interfaces  to 
the  Platform  structure.  These  modules  can  be  removed  in  orbit 
from  the  platform  structure  and  be  replaced  with  new  modules  at 
the  same  interface. 

The  platforms  are  expected  to  remain  operating  in  orbit  con- 
tinuously for  30  years.  They  will  be  maintained  by  periodic 
servicing  visits  for  instrument  module  exchange  or  change  of 
platform  operating  sub-system  modules  for  repair.  Servicing 
visits  would  be  by  NSTS  to  a platform,  or  by  returning  a plat- 
form to  the  Space  Station.  A servicing  facility  on  Space 
Station  will  be  provided,  where  servicing  work  on  platforms 
and  other  spacecraft  will  be  performed.  Servicing  visits  of 
platforms  would  occur  at  intervals  of  1 year  or  longer. 

Although  platforms  will  orbit  separately  from  the  Space 
Station,  they  are  elements  of  the  Space  Station  Program. 
Therefore,  the  ground  operations  system  to  support /process  them 
will  be  integral  with  the  ground  operations  system  to  maintain 
the  Space  Station  itself. 

Initially,  platform  modules  would  be  verified  for  proper 
function  and  operation  through  their  platform  interface  during 
the  platform  buildup  process,  in  the  same  manner  as  other  Space 
Station  payloads.  After  platforms  are  in  orbit,  final  ground 
verification  of  new  experiment  and  sub-system  module  interfaces 
to  the  orbiting  platforms  will  be  done  with  mechanical  and 
electrical  simulators  of  the  standard  platform  interfaces  that 
are  as  high  quality  as  is  feasible.  The  location  of  the  final 
interface  test  of  platform  modules  is  expected  to  be  at  GSFC, 
under  direction  of  PIO.  Final  checkout  of  the  platform  modules 
would  be  on  the  platform  in  orbit. 

The  Space  Station  Program  will  not  have  the  responsibility  to 
maintain  other  free-flying  spacecraft  owned  by  other  groups, 
but  will  service  them  as  their  owners  request.  Equipment  to 
support  the  other  spacecraft  that  passes  through  the  Space 


Station  logistics  system  will  be  handled  essentially  the  same 
way  as  user  resupply  items  used  to  maintain  user  experiment 
equipment  onboard  Space  Station.  The  PIO  will  assure  that 
tests  show  those  items  are  safe  for  Space  Station,  but  the 
uaers  must  make  their  own  assurance  of  fit  and  function. 
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Appendix  E 

SUSTAINING  ENGINEERING 


FUNCTIONAL  DESCRIPTION  OUTLINE 

This  section  is  an  outline  definition  of  the  Sustaining 
Engineering  functions  necessary  to  support  operations  of  the 
Space  Station  Program.  These  functions  are  replicable  to  any 
area  of  Sustaining  Engineering  organizations.  The  scope  of  this 
effort  is  flight  hardware  and  software,  ground  systems  hardware 
and  software,  ground  support  equipment  and  ground  processing 
software,  and  support  to  customer  integration.  The  sustaining 
engineering  functional  area  includes: 

o Performing  the  analysis  and  engineering  necessary  to 
maintain  and  enhance  the  Space  Station  Program  orbital 
and  ground  support  program  elements. 

o Designing,  building,  and  supporting  the  installation 
and  integration  of  approved  modifications  to  the 
program  elements. 

o Developing  and  maintaining  integration  and 

verification  requirements  for  flight  systems,  ground 
systems,  and  the  interfaces  to  customer  systems, 
transportation  systems,  and  institutional  tracking, 
data  relay,  and  ground  data  communications  systems. 

o Performing  the  day-to-day  management  of  approved 
program  configurations  and  supporting  the  overall 
configuration  management  and  control  program. 

FUNCTION  OUTLINE: 

1.  Planning  and  Management 

2.  Systems  Analysis 

3 . Design  Engineering 

4.  Engineering  Integration  and  Verification 

5.  Documentation 
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SPB  FUNCTIONS : 


1.  Planning  and  Management 

A.  Planning  and  Scheduling 

B . Budget  Management 

C . Contract  Management 

D.  Resource  Management 

E.  Manage  Station  System  Advanced  Technology  Programs  - As 
Assigned 

F.  Evolution  and  Growth  Management  - (Space  Station  Impacts) 

2.  Systems  Analysis 

A.  Flight  Certification  Engineering  Analysis  (from 
customer  recommendations  and  station/platform  system 
modifications  and  enhancements) 

B.  Systems  Performance  Analyses  - Conduct  Trend  Analyses 
and  Evaluate  Test  Data 

C.  Provide  Analyses  of  System  Performance  Degradations 

D.  Identify  Requirements  for  Operational  Performance 
Enhancements 

E.  Failure  Analyses 

F.  Mass  Properties  Analyses  and  Configuration  Analysis 

G.  Support  the  Feasibility  and  Supportability  Analyses  of 
Proposed  Enhancements  and  Modifications 

H.  Technical  Risk  Assessments  - for  flight  and  ground 
support  hardware  and  software  systems 

1.  Criticality  Assessments 

2.  Failure  Mode  and  Effects  Analyses 

3.  Single  Point  Failure  Analysis 

4.  Safety  and  Hazard  Analyses  and  Assessments 

5.  End-to-End  Analysis 

6.  Sneak  Circuit  Analysis 

7 . Control  Logic  Reviews 
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8.  Feasibility 

9.  Availability 

10.  Commonality 

11.  Maintainability 

12.  Operability 

13.  Cost 

14.  Schedule 

I.  Environmental  Analysis  and  Control 

1.  Vibration  Analysis 

2.  Acoustical  Analysis 

3.  Thermal  Loads  Analysis 

4.  RFI  Analysis 

5.  Load  Stress  Analysis 

3 . Design  Engineering 

A.  Design  and  Engineering  of  Flight  Systems  and  Ground 
Support  Systems 

Enhancements /Modif ications 

1.  Conceptual,  Preliminary,  and  Detailed  Design 
Products  (includes  documentation,  analyses,  and 
reviews ) 

2.  Integrated  Design  Reviews 

3.  Specifications,  Drawings,  Requirements 

4.  Design  Criteria 

5.  Design  Verification  Requirements 

6.  O&M  Documentation 

7.  Installation/Modification  Requirements 

8.  Preparation  and  Maintenance  of  "As-Built"  Drawings, 
Specifications  and  S/W  Source  Code  Listings 

9.  Systems  Reconfiguration  and  Installation 
Requirements.  Also  Includes  Payload 
Installation/Removal  Requirements.  Includes 
Schematics,  Installation/Removal  Instructions  and 
Software  Products. 

10.  Transportation  Configuration  Design 

B.  Design  of  Test  Article  Hardware,  Software,  and  Ground 
Support  Equipment 

4.  Engineering  Integration  and  Verification 

A.  Modification  Enhancement  Hardware  and  Software 
Integration  and  Implementation 
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1.  Flight  Systems 

2 . Ground  Systems 

3.  Customer  Systems  to  Flight /Ground  Systems 

4.  Flight/Ground  Systems  to  Transportation  Systems 

5.  Flight /Ground  Systems  to  Institutional  Tracking, 

Data  Relay,  and  Ground  Data  Communications  Systems 

B.  Customer  to  System/Subsystem  Integration,  Verification, 
and  Compatibility  Assessments 

C.  Verification  Testing  Planning 

1.  Test  Objectives  and  Requirements 

2.  Evaluation  Criteria 

3.  Test  Procedures  and  Plan 
4*  Training 

5.  Scheduling 

D.  Support  to  Verification  Testing  (testing  performed  by 
operations ) 

E.  Customer-System  Interface  Engineering.  Includes 
Customer-System  Interface  Designs  as  Required 

F.  "Build"  Process 

1.  Make  or  Buy  Decisions 

2 . Procurement  Support 

a . Hardware 

b . Software 

c.  Materials 

d.  Services 

G.  Real-Time  Engineering  Support  to  Operations 

1.  Engineering  for  Anomaly  Resolution 

2.  Systems  Performance  Monitoring 

3.  Engineering  for  Critical  Operations 

H.  Integrate  and  Coordinate  Evaluations,  Assessments, 

Analysis,  and  Anomaly  Resolution 

5 . Documentation 

A.  Maintain  and  Update  Flight  Hardware  ICD's 

B.  Maintain  and  Update  Flight  S/W  Source  Code  Listings 

C.  Maintain  and  Update  Ground-Flight  Systems  ICD's 
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0.  Maintain  and  Update  Ground  System  S/W  Source  Code 
Listings 

E.  Maintain  and  Update  Architecture  Control  Documents 
(ACDs) 

F.  Design  Documentation 

G.  Configuration  Status  and  Updates  (Data  Base  Products) 

H.  Mass  Property  Documentation 

1.  Performance  Trend  and  Prediction  Reports 

J.  Design  Review  Packages 

K.  Analysis  Reports 

L.  Flight  Certification  Status 

M.  Commonality  Identification  and  Status 

N.  Access  Requirements  to  Customers,  Space  Station  Elements,  and 
Support  Systems 

O.  Updates  to  Controlled  Documentation  is  Approved  by 
Configuration  Management 


c - £> 
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APPENDIX  F 


CONFIGURATION  MANAGEMENT 
FUNCTIONAL  DESCRIPTION  OUTLINE 


This  section  is  an  outline  description  of  the  configuration 
management  Functions  required  to  support  the  Space  Station 
Program.  These  functions  are  replicable  to  any  level  of 
configuration  management  Systems. 

Day  to  day  activities  are  a mixture. 


Very  Top-Level  function  can  be  strategic  - i.e..  Bilateral 
Agreements  to  change  the  Fundamental  Configuration  of  the  Space 
Station  Flight  or  Support  Systems. 

FUNCTION  OUTLINE; 


1. 

2. 

3. 

4.. 


Configuration  Identification 
Configuration  Control 
Configuration  Verification  (Auditing) 
Configuration  Accounting 


SUBFUNCTIONS : 


1.  Configuration  Identification 

A.  Selecting  End  Items  of  Hardware  and  Software  to  Come 
Under  Configuration  Control 

B.  Develop  and  Maintain  Baseline  Identification  of  H/W  and 
S/W  Under  Configuration  Control 

C.  Develop  and  Maintain  Engineering  Documentation 

1.  Prepare  and  Maintain  H/W  & S/W  Specifications, 
Drawings,  and  S/W  Source  Code  Listings 

2.  H/W  & S/W  Engineering  Documentation  and  Computer 
Program  Media  Records  and  Releases 

2.  Configuration  Control 


A. 


Controlling  H/W  & S/W  Such  That  Demonstrated  Physical 
Status  and  Performance  Satisfy  Mission,  Safety,  and 
Security  Requirements 
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B.  Managing  Changes  to  the  Baseline  System  Through  a 
Formal  Review  and  Approval  Process  Prior  to  Directing 
H/W  & S/W  Changes 

C.  Closing  Out  Configuration  Change  Directives  Upon 
Completion  of  the  Configuration  Verification  and 
Configuration  Accounting  Processes 

3.  Configuration  Verification  (Auditing) 

A.  Conduct  Reviews  to  Assure  that  the  Design  of  the  Changes 
to  the  Baseline  Configuration  Satisfies  Approved 
Requirements  (Mission,  Safety,  & Security) 

B.  Conduct  Reviews,  Tests,  Inspections,  etc.,  to  Assure 
that  H/W  or  S/W  End  Items  Conform  to  the  Released  Design 
Documentation 

C.  Conduct  Reviews,  Tests,  Inspections,  etc.,  to  Assure 
that  the  Modifications  Have  Been  Incorporated  in 
Accordance  with  the  Configuration  Change  Directive 
(i.e..  Verify  "As-Built"  is  the  Same  as  "As-Designed") 

D.  Conduct  Periodic  Reviews  and  Audits  to  Verify  that  the 
Change  Control  Process  is  Effective 

4.  Configuration  Accounting 

A.  Establish  and  Maintain  a Data  Collection  and  Storage 
System  Which  Provides  for  Tracking  and  Auditing  the 
Change  Control  Documentation.  These  Include  Change 
Requests,  Disposition  Actions  for  Change  Requests,  and 
Verification  Reports 

B.  Provide  Approved  Inputs  to  the  System(s)  Containing  the 
Identification  of  the  Baseline  Systems 

C.  Manage  Program  Configuration  Data  Base(s) 


APPENDIX  G 

Sustaining  Engineering  and  Configuration  Control 
Scenarios /Schemes  for  the  Space  Station 
Program  Operational  Era 


Glenn  R.  Parker 


INTRODUCTION 

After  the  Space  Station  Program  (SSP)  becomes  fully  operational, 
the  methods  by  which  the  engineering  changes  associated  with  SSP 
maintenance,  modifications,  upgrades,  and  overall  evolution  are 
handled  and  managed  will  be  similar  to  those  methods  that  are 
implemented  during  the  SSP  Design,  Development,  Test,  and 
Evaluation  (DDT&E)  phase,  but  the  management  scheme  for  these 
methods /functions  should  be  different  than  that  employed  for  the 
early  DDT&E  phase  of  the  program.  Required  management  and 
operational  response  time,  efficiency,  and  cost  effectiveness 
will  dictate  that  an  evolution  in  sustaining  engineering  and 
change  management  schemes  take  place  that  will  allow  such 
systems  to  be  operationally  oriented  and  streamlined  in  order 
for  the  program  to  cope  efficiently  with  the  multifaceted 
scenarios  that  will  exist  during  the  SSP  operational  era.  These 
scenarios  will  probably  be  different  than  those  faced  early  in 
the  program  due  to  the  increased  complexity  in  SSP  subsystems/ 
systems,  operations,  and  interrelationships/  interdependence 
with  other  program/agency  elements.  This  treatise  will  describe 
typical  engineering  change  scenarios  that  might  occur  during  the 
SSP  operational  era,  and  will  also  describe  operational  change 
management  and  sustaining  engineering  schemes  that  could  be 
utilized  to  handle  these  scenarios. 

ENGINEERING  CHANGE  SCENARIO  DESCRIPTION 

• 

For  the  purposes  of  this  paper,  two  typical  engineering  change 
scenarios  that  might  occur  during  the  SSP  operational  era  are 
considered.  It  is  realized  that  other  scenarios  may  exist  which 
will  be  different  than  those  described  herein,  or  that  a combi- 
nation of  scenarios  may  exist  that  embodies  some  elements  of 
those  described  herein.  However,  these  two  scenarios  are  felt 
to  be  representative  of  the  boundary  conditions  that  will  exist 
for  such  changes  that  may  occur  during  this  era.  The  two  chosen 
scenarios  are: 

(1)  An  engineering  change  that  affects  multi  program/agency 
elements  such  as  the  Space  Station  Program  elements.  Interna- 
tional elements  that  are  a part  of  the  SSP,  National  Space 
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Transportation  System  (NSTS)  elements  (e.g.r  Orbiter),  and  other 
program/ agency  elements  such  as  users  (customers),  the  Tracking 
Date  Relay  Satellite  System  ( TDRSS ) , and/or  the  Global  Position- 
ing System  (GPS).  Examples  of  such  changes  are:  a.)  A change  to 
the  basic  station  electrical  power  scheme  involving  wiring  size 
changes,  electrical  frequency  changes,  load  carrying  capabili- 
ties, etc.,  b.)  changes  in  data  rate/channel  requirements,  high 
resolution  video  requirements,  or  uplink/downlink  data  require- 
ments, and  c.)  a requirement  for  Orbiter  control  of  the  Station 
Remote  Manipulator  System.  Such  changes  would  not  only  affect 
D.  S.  Space  Station  Element  subsystems / systems , but  could  affect 
international  element,  customer,  Orbiter,  TDRSS,  and/or  GPS 
subsystems /systems,  dependent  upon  the  example  considered. 

(2)  An  engineering  change  that  affects  only  the  U.S.  supplied 
elements  of  the  SSP  and  does  not  involve  any  other  supplied 
elements  of  the  SSP  or  any  other  elements  of  various  pro- 
grams /agencies.  An  example  of  such  a change  might  be  a change 
involving  the  addition/upgrade  of  a work/maintenance  bench  in 
the  U.S.  Laboratory  or  Habitation  Module. 

For  each  of  these  scenarios,  a proposed  operational  era  engi- 
neering change  management  and  sustaining  engineering  scheme  will 
be  presented  and  described. 

OPERATIONAL  CHANGE  MANAGEMENT  AND 
SUSTAINING  ENGINEERING  SCHEME 

Typically,  early  phases  of  any  program  utilize  a change  manage- 
ment and  sustaining  engineering  scheme  that  involves  the  program 
manager,  the  program's  project  managers,  a configuration  manage- 
ment team,  a systems  engineering  and  integration  (SE&I)  team, 
project  systems  engineering  experts,  and  a distributed  change 
evaluation  process  to  evaluate,  disposition,  and  implement 
program/project  change  requests  (CR's).  The  program/  project 
managers  usually  have  all  of  the  approval /disapproval  authority 
for  the  purposes  of  dispositioning  such  CR's,  and  operations 
personnel  are  usually  only  a part  of  the  submittal  and/or  the 
change  evaluation/  implementation  process.  As  such,  operations 
personnel  have  very  little  control  over  their  own  destiny,  and 
operational  considerations,  including  cost,  often  are  not 
properly  considered  during  the  change  control /management 
process.  During  the  operational  era  of  the  SSP,  and  other  pro- 
grams, a change  management  and  sustaining  engineering  scheme 
should  evolve  to  one  that  is  primarily  controlled  by  operations 
personnel  via  a single  Program  Operations  Manager,  who  is  in 
charge  of  both  flight  and  ground  operations  for  the  program(s). 
The  appeal  route  for  such  a scheme  would  be  from  the  Program 
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Operations  Managers  to  an  Associate  Administrator  for  Opera- 
tions. A proposed  top-level  organizational  structure  for  such  a 
scheme  is  depicted  in  Figure  1.  Such  a structure  would  replace 
the  normal  structures  that  exist  during  the  early  phases  of 
various  programs.  The  operational  era  structure  would  make  a 
change  management  and  sustaining  engineering  scheme  more  opera- 
tionally controlled  and  oriented,  in  tune  with  operational 
needs,  more  streamlined,  and,  hopefully,  more  cost  effective. 

In  a program's  operational  era,  it  would  be  desirable  if  all 
programs  could  evolve  their  organizational  structure,  change 
management  schemes,  and  sustaining  engineering  schemes  along 
such  a philosophy  to  facilitate  inter-program  compatibility. 

With  such  a philosophy  in  place,  an  engineering  change  and/or 
sustaining  engineering  effort  that  affected  the  SSP  only  would 
be  supported  by  the  "generic"  change  management  and  sustaining 
engineering  scheme  shown  in  Figure  2.  An  example  of  such  a 
change,  as  previously  mentioned,  might  be  an  addition  of  an/or 
upgrade  to  a work/maintenance  bench  in  the  O.S.A.  supplied 
Labratory  or  Habitation  Modules. 

If  a change  affected  multiple  programs,  such  as  the  SSP,  the 
NSTS  program,  and  the  Canadian  (International)  program,  the 
"generic"  change  management  and  sustaining  engineering  scheme 
would  be  expanded,  as  shown  in  Figure  3,  to  encompass  the  three 
programs.  An.  example  of  such  a change  would  be  one  that  re- 
quired a modification  to  allow  for  control  of  the  Space  Station 
Manipulator  Arm  (MRMS ) from  the  Orbiter  Aft  Flight  Deck. 

Finally,  if  a change  affected  all  programs  that  may  be  interre- 
lated with  the  SSP,  during  the  operational  era,  the  "generic" 
change  management  and  sustaining  engineering  scheme  would  be 
further  expanded,  as  shown  in  Figure  4. 

The  only  differences  between  the  three  schemes  are  the  number  of 
participants  involved  and  the  magnitude  of  the  required  integra- 
tion effort  among  the  various  involved  programs.  However,  the 
same  basic  eleven  step  process  would  be  followed  for  all  of  the 
depicted  schemes.  In  order  to  describe  the  basic  eleven  step 
process  of  these  change  management  and  sustaining  engineering 
schemes,  the  example  depicted  by  Figure  3 is  chosen.  This 
example  was  chosen  because  it  adequately  depicted  the  complexity 
associated  with  multi-program  interrelationships,  while  at  the 
same  time  remaining  simple  enough  in  scope  to  allow  the  reader 
to  relate  to  the  "generic”  scheme.  In  describing  the  basic 
eleven  step  process,  it  should  not  be  assumed  that  all  changes 
must  go  through  the  entire  process.  Some  changes,  such  as 
'quick  turn  changes'  or  changes  to  basic  customer's  hard- 
ware/software, may  be  able  to  skip  some  steps.  These  factors 
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TOP-LEVEL  ORGANIZATIONAL  STRUCTURE 

FOR 

CHANGE  MANAGEMENT  AND 
SUSTAINING  ENGINEERING 
DURING  OPERATIONAL  FLOW 
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would  be  considered  on  a case-by-case  basis.  However,  what 
follows,  is  a basic  description  of  the  eleven  step  process  for 
the  change  example  chosen. 

OPERATIONAL  CHANGE  MANAGEMENT 
AND  SUSTAINING  ENGINEERING  SCHEME 
STEP  DESCRIPTION 

STEP  #1  ~ Requirement  Initiation  - An  engineering  change  could 
be  initiated  by  anyone  from  any  program/agency  at  any  level. 

Such  a change  request  could  be  in  the  from  of  a Program/Project 
Change  Request  (CR),  an  Engineering  Support  Request  (ESR), 
Engineering  Change  Proposal  (ECP),  or  any  other  program  equiva- 
lent. For  the  purpose  of  this  paper,  a generic  term,  "Change 
Request  (CR)”,  will  be  used  to  describe  such  changes. 

When  the  CR  enters  the  system,  a requirements  initiation  team 
would  receive  it  and  perform  the  following  functions: 

A.  The  team  would  determine  whether  the  change  affected  the 
usage  of  the  station  and/or  operations,  whether  the  change 
represented  an  enhancement  to  present  station  design,  or  whether 
the  change  was  needed  to  resolve  a problem  on  board  the  station. 
It  would  also  determine  if  one  or  more  programs/agencies  were 
affected  by  the  CR. 

B.  The  team  would  determine  the  criticality  of  the  change. 

C.  The  team  would  assess  the  change  rationale  and  insure  that 
the  originator  had  included  enough  information  with  the  CR  (eg. 
design  concepts,  etc.)  to  allow  for  a future  impact  assessment. 

D.  The  team  would  prepare  and  forward  an  Engineering  Support 
Request  (ESR),  or  equivalent,  that  reflected  the  original  CR. 

The  ESR  would  be  forwarded  to  the  appropriate  screening  boards, 
where  Step  #2  of  the  process  would  begin. 

STEP  #2  - Screening  Board  - The  screening  boards  would  be 
chaired  by  the  Program  Operations  Managers  or  designate  and 
supported  by  various  operations  discipline  and  SE&I  discipline 
personnel  such  as  logistics  personnel,  customer  (user)  represen- 
tatives, engineering  personnel,  operations  personnel,  manifest 
personnel,  safety  reliability  and  quality  assurance  (SR  & QA) 
personnel,  etc.  Each  program/agency  affected  by  the  change 
would  have  a similar  arrangement.  The  purpose  of  the  screening 
boards  would  be  to  initially  screen  the  change  and  provide  for  a 
preliminary  disposition  in  order  to  keep  unwanted  changes  from 
choking  the  full  assessment  process.  Upon  receiving  the  ESR, 
the  screening  boards  would  perform  the  following  functions: 
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A.  The  screening  boards  would  perform  an  initial  validation  of 
the  ESR  to  determine  if  the  change  paper  contained  enough 
information  for  an  assessment,  if  the  change  rationale  and 
criticality  assessments  were  proper,  and  if  the  change's  effect 
on  their  programs  design/operations  were  properly  assessed. 

Each  screening  board,  via  its  SE&I  personnel,  would  perform  an 
initial  integration  task  to  insure  that  the  above  tasks  were 
accomplished  and  that  an  integrated  assessment  existed  across 
all  affected  programs/agencies. 

B.  The  screening  boards  would  determine  the  changes  category 
(ie  mandatory,  highly  desirable,  etc.),  its  effectivity  (eg. 
one  or  more  orbiters),  and  would  perform  an  initial 
determination  of  how  the  change  would  be  manifested  for  launch 
or  by  which  flight  it  would  be  implemented.  Again,  each 
screening  board's  SE&I  support  would  insure  that  an  integrated 
assessment  existed  across  all  affected  programs /agencies . In 
addition, the  screening  boards  manifesting  personnel  would  work 
with  any  other  SSP/NSTS  manifesting  experts  (e.g.,  a Tactical 
Operations  Control  Board)  to  properly  coordinate  manifesting. 

C.  Finally,  each  screening  board  would  provide  their  initial 

disposition  of  the  change.  The  dispositions  would  take  one  of 
two  forms:  (1)  Approval  for  further  full  assessment  of  the 

change  by  a change  assessment  team,  or  (2)  Disapproval  of  the 
change,  which  would  result  in  no  further  action  regarding  the- 
change.  Any  disagreement  between  dispositions  of  any  of  the 
affected  screening  boards  would  result  in  a conflict  resolution 
appeal  to  the  Associate  Administrator  for  Operations.  Such  an 
appeal  route  would  also  be  available  to  the  CR  originator.  If 
all  of  the  screening  boards  approved  the  ESR  for  further  assess- 
ment, or  if  the  Associate  Administrator  for  Operations,  directed 
approval,  then  the  ESR  would  be  forwarded  to  an  Assessment  Team 
for  each  affected  program/agency  and  Step  #3  of  the  process 
would  begin. 

Step  #3  - Assessment  - An  assessment  team  for  each  effected 
prograro/agency  would  perform  the  following  functions: 

A.  The  teams  would  develop  an  implementation  plan  and  schedule 
for  the  change. 

B.  The  teams  would  determine  the  Rough  Order  of  Magnitude 
(ROM)  costs  for  the  change  and  assess  the  required  contract 
changes  for  their  programs. 

C.  The  teams  would  initiate  and  complete  any  required  studies 
that  might  result  because  of  the  change. 
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D.  The  teams  would  determine  any  other  impacts  resulting  from 
the  change  (e.g.,  weight  impacts,  launch  slip  impacts,  etc.). 

E.  The  teams  would  assess  the  interfaces  affected  by  the 
change  and  prepare  appropriate  ICD/IRD  changes. 

F.  Each  team,  via  its  SE&I  personnel,  would  coordinate  with 
each  other  to  insure  that  an  integrated  assessment  would  be 
achieved. 

G.  Upon  completing  an  integrated  assessment,  the  teams  would 
forward  the  assessment  in  the  form  of  an  Engineering  Analysis 
and  Cost  Assessment  (EACE),  or  equivalent,  to  a Joint  Change 
Evaluation  Board,  which  would  begin  Step  #4  of  the  process. 

Step  #4  - Joint  Change  Evaluation  Board  - A Joint  Change  Evalua- 
tion Board  would  receive  the  EACE  for  consideration.  This  board 
would  be  chaired  by  the  SSP  Program  Operations  Manager  and 
supported  by  similar  operations  managers  from  all  other  affected 
programs/agencies,  each  with  an  equal  vote.  The  functions  of 
this  board  would  be: 

A.  The  Board  would  either  approve  or  disapprove  the  change. 

If  the  Board  disapproved  the  change,  no  further  action  on  the 
change  would  occur,  unless  a subsequent  appeal  to  the  Associate 
Administrator  for  Operations  reversed  the  decision.  Upon  Board 
approval  of  the  change,  a joint  Change  Control  Board  Directive 

( CCBD ) would  be  issued  to  the  Design  and  Engineering  Organiza- 
tions of  the  affected  programs/agencies,  and  Step  #5  would 
begin. 

B.  In  considering  the  change,  the  Board  might  also  issue 
further  actions  regarding  the  change  or  as  a result  of  the 
change.  The  Board  could  also  return  the  change  back  to  the 
respective  Assessment  Teams  for  further  reassessment. 

C.  The  Board  would  also  issue  Contract  Change  Authorizations 
(CCA's)  to  the  involved  contractors  of  each  affected  program/ 
agency,  and  would  notify  the  affected  manifesting/logistics 
personnel  of  the  decision  so  that  proper  manifesting/logistics 
planning  could  begin. 

Step  #5  - Design  and  Engineering  - Each  program/agency  Design 
and  Engineering  organization  would  receive  their  respective 
CCBD's,  and  begin  the  normal  activities  for  implementing  the 
change.  These  activities  would  include: 

a.  defining  the  detailed  design  requirements  and  specifica- 
tions. 
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b.  preparing  drawings  and/or  implementation  instructions, 

c.  defining  detailed  verification  and  test  requirements, 

d.  supporting  the  preparation  of  test  procedures  and/or 
analyses , 

e.  updating  various  affected  ICD' s/IRD' s/ACD' s/BCD' s 

f.  conducting  appropriate  design  and  safety  reviews,  and 

g.  performing  appropriate  assurance  analyses. 

Each  program' s /agency ' s SE&I  staff  would  be  responsible  for 
integrating  their  own  activities  and  coordinating  with  the  other 
affected  SE&I  staffs  in  order  to  assure  an  integrated  approach 
to  the  design  and  engineering  effort.  From  this  effort. 

Document  Release  Authorizations  (DRA's),  or  equivalent,  would  be 
released  to  each  program' s/ 'agency ' s manufacturing  personnel  to 
begin  Step  #6  of  the  process. 

Step  #6  - Hardware/Software  Build  - Each  program' s /agency ' s 
manufacturing  team  would  begin  the  process  of  actually  building 
the  hardware/software  associated  with  the  change  modification. 
These  efforts  would  include: 

A.  support  for  the  procurement  of  the  piece  parts  and/or 
software  code  from  the  vendors  (subcontractors/contractors), 

B.  the  support  required  for  the  actual  fabrication  of  each 
program' s /agency ' 8 hardware  portion  of  the  modification,  and  the 
support  required  for  the  building  of  software  programs  required 
by  any  prograro/agency , 

C.  the  processing  of  any  waivers /deviations  required  to  the 
original  design,  including  coordination  between  each  program/ 
agency  by  their  respective  SE&I  personnel, 

D.  the  processing  of  engineering  changes  to  the  original 
modification  design,  to  facilitate  the  manufacturing  process,  by 
each  affected  program/agency,  along  with  appropriate  integration 
of  these  changes  by  the  affected  SE&I  personnel , and 

E.  the  factory  verification  support  from  each  program/agency 
for  their  portion  of  the  modification,  including  development 
through  final  acceptance  verification  and  certification.  Such 
verification  would  also  include  an  integrated  certification  and 
acceptance  verification  for  the  end-to-end  system  affected  by 
the  modification  using  actual  flight  hardware /software  and/or 
simulators  as  required.  Such  verification  would  be  coordinated 
and  integrated  by  each  program' s /agency ' s SE&I  personnel. 
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Once  this  step  is  complete,  each  program/agency  would  ship  their 
portion  of  the  mod-kit  to  the  launch  site,  where  the  final  phase 
of  this  scheme  would  begin  with  Step  #7. 

Step  #7  - Change  Package  Support  - Each  program/agency  would 
have  engineering  and  management  support  personnel  located  at  the 
launch  site  to  help  perform  this  step,  which  would  include  the 
following  functions:  (NOTE:  The  actual  hands-on  work  at  the 

launch  site  would  be  performed  in  accordance  with  established 
methods  of  operating.) 

A.  the  shipping,  receiving  and  quality  assurance  (QA)  inspec- 
tion for  each  program' s /agency ' s portion  of  the  mod-kit, 

B.  the  final  assembly  and  staging  for  each  portion  of  the 
mod-kit  along  with  stand-alone  power-on-testing  that  would  be 
required,  and 

C.  the  preparation  of  any  final  engineering  documentation 
associated  with  any  portion  of  the  mod-kit  required  for  final 
installation  and  integrated  testing. 

Once  this  step  is  complete,  the  mod-kit  portions  would  be  turned 
over  to  the  SSP  launch  site  personnel  for  the  beginning  of  Step 
#8. 

Step  #8  - Verification  - SSP  launch  site  personnel  would  receive 
each  program' s /agency ' s portion  of  the  mod-kit  and,  off-line 
from  the  NSTS  processing,  integrate  the  rood-kit  into  a total  on- 
orbit  configuration  using  actual  flight  hardware  and  appropriate 
simulators.  This  would  be  done  to  accomplish  both  single  and 
multiple  launch  package  integration  and  verification  to  assure 
that  the  mod-kit  will  operate  as  designed  with  station/orbiter 
hardware/software  that  is  already  on-orbit.  In  addition,  such 
verification  could  augment  crew  training  and  be  used  to  verify 
on-orbit  flight  procedures.  Once  this  step  is  complete.  Space 
Station  personnel  could  begin  Step  #9  of  the  process. 

Step  #9  - Transportation  Support  - Space  Station  personnel  would 
prepare  a configuration  definition  and  mass  property  analysis 
for  installing  various  portions  of  the  mod-kit  in  the  Orbiter 
Aft  Flight  Deck,  Orbiter  Payload  Bay,  and/or  the  SSP  Logistics 
elements.  Close  coordination  between  the  SSP  and  NSTS  SE&I, 
Logistics,  and  Ground/Flight  Operations  personnel  would  be 
required  to  assure  that  orbiter  mods  were  properly  scheduled, 
logistics  elements  were  properly  manifested,  that  the  Orbiter 
Payload  Bay  and/or  Aft  Flight  Deck  was  properly  manifested,  and 
that  on-orbit  station  installation  and  checkout  operations  were 
properly  scheduled.  Once  these  function  were  completed.  Step 
#10  of  the  process  would  begin. 
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Step  #10  - Installation  and  Checkout  - Each  affected  program/ 
agency  would  begin  the  task  of  supporting  and/or  installing/ 
manifesting,  as  appropriate,  portions  of  the  mod-kit  into  their 
affected  hardware /software  subsystems/systems.  Actual  hands-on 
work  would  be  accomplished  by  established  methods  of  operating, 
installations  would  be  followed  by  appropriate  support  for  final 
verification  and  checkout  of  the  affected  subsystems / systems . 
This  installation/checkout  could  occur  on  the  ground  and/or 
on-orbit,  and  would  be  followed  by  an  analysis  of  predicted  data 
and  the  processing  of  any  final  waivers/deviations  by  each 
affected  program/agency.  At  the  completion  of  this  task, 
"installation  complete  (INC)"  notices  would  be  given  to  each 
affected  program's/agency's  configuration  management  and  verifi- 
cation personnel  teams  to  begin  Step  #11  of  the  process. 

Step  #11  - Configuration  Dpdate  - Each  program' s /agency ' s 
configuration  management  and  verification  personnel  teams  would 
accomplish  the  final  step  of  this  process,  which  would  include: 

A.  updating  all  drawings  and  documentation  to  the  as-build 
conf iguration , 

B.  providing  CCBD  closeout  documentation, 

C.  completing  verification  completion  notices,  or  equivalent, 
(VCN's)  and  updating  the  appropriate  verification  data  bases, 

D.  performing  any  other  required  configuration  accounting 
actions  required  by  each  affected  prog ram /agency. 

The  completion  of  the  step  would  complete  the  entire  change 
management  and  sustaining  engineering  effort  for  such  a change. 

SUMMARY 

This  paper  has  attempted  to  deal  with  one  aspect  of  the  sustain- 
ing engineering  effort  required  for  the  SSP  and  other  interre- 
lated programs  during  the  SSP  operational  era  - the  "Change 
Management /Implementation  Process".  The  proposed  change  manage- 
ment scheme  is  but  one  way  that  such  a scheme  could  evolve,  but 
it  is  felt  that  such  an  evolution,  or  a similar  one,  will  be 
necessary  if  the  SSP  is  to  cope  with  the  operational  complexi- 
ties that  will  exist  during  this  era. 


G-13 


APPENDIX  H 


Ocean  Systems  Engineering,  Inc. 

FRF-108-87 
February  27,  1987 


C.  Mars/SS-OTF 
Nasa  K.S.C. 

Kennedy  Space  Center,  FL  32899 
Dear  Mr.  Mars, 

Attached  is  our  "White  Paper"  giving  an  overview  of  the  develop- 
ment of  teleoperated  work  systems  for  sustaining  engineering 
applications.  I have  also  included  a section  on  the  development 
and  application  of  a 30  year  sustaining  engineering  program. 
Finally,  there  are  papers  that  address  the  subsea  approach  to 
work  systems  development  and  one  on  applying  the  man/machine 
synergy  to  subsea  operations. 

If  you  have  any  questions  or  need  any  additional  information, 
give  me  a call. 

Respectfully  yours. 


F.  Richard  Frisbie,  P.E. 
President 

FRF : em 

Attachment 

CC:  J.  R.  Huff 
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1441  Park  Ten  Blvd.,  Houston,  Texas  77084  Telex:  762454  OCEAN  SYS  ENG  (713)  492-2800 


An  Overall  Review  of  the  Development  of  Teleoperated  Systems 
and  Sustaining  Engineering  Programs  in  the  Deepwater  Industry 
F.R.  Frisbie/M.L.  Gernhardt  - Ocean  Systems  Engineering 


The  subsea  industry  has  been  involved  in  performing  subsea  work 
in  support  of  the  offshore  oil  and  gas  industry  for  the  past 
twenty  years.  Initially,  none  of  the  subsea  equipment  was 
designed  for  serviceability  and  all  the  work  tasks  were  performed 
by  hands  on  divers  (analogous  to  gloved  astronauts) . As  oil  and 
gas  drilling  and  production  moved  into  deeper  water  depths,  a 
number  of  advanced  work  systems,  tools  and  techniques  evolved  to 
service  the  associated  subsea  equipment. 

These  advanced  work  systems  evolved  from  atmospheric  diving 
suits  with  mechanical  end-effectors,  to  manned  submersibles  with 
manipulators,  on  to  a large  variety  of  tele-operated  manipulator 
work  systems. 

Presently  we  are  now  beginning  work  on  developing  autonomous 
robots  with  low  level  artificial  intelligence. 

Development  of  Remote  Work  Capabilities 

The  evolution  of  these  work  systems  has  been  shaped  by  the 
simultaneous  demands  of  safety,  cost  effectiveness,  reliability, 
flexibility  and  ease  of  maintenance  and  repair.  Over  the  past 
20  years  the  subsea  industry  has  gained  several  million  hours  of 
operating  experience  with  these  systems.  Through  this  experience 
we  have  learned  the  types  of  tasks  that  various  systems  performed 
well,  the  tasks  they  don't  perform  well,  and  the  special  tooling 
and  interface  engineering  that  can  be  applied  to  greatly  improve 
the  systems'  performance. 

One  of  the  most  fundamental  lessons  that  our  industry  learned  is 
that  the  performance  and  efficiency  of  tele-operated  manipulators 
is  determined  more  by  function  of  the  task  design,  task- t ©-manip- 
ulator interfaces,  and  manipulator  tools  than  of  the  manipulator 
itself.  This  lesson  came  from  hard  experience.  Initially,  all 
of  our  engineering  efforts  went  into  developing  more  sophisti- 
cated manipulators.  The  resulting  manipulators  (produced  in  the 
1970 ’s)  were  quite  sophisticated  and  probably  unmatched  even 
today.  These  manipulators  incorporated  six  degrees  of  freedom 
and  seven  controllable  axis  with  a compliant,  spatially  corres- 
pondent, inverse  kinematic  control  system  based  on  a master/slave 
user  interface.  They  also  incorporated  force  feedback  and 
dynamic  compliance,  allowing  the  operator  to  feel  the  loads 
imposed  on  the  master.  Stereo  video  cameras  and  hydrophones  were 
employed  to  increase  the  tele-presence  capabilities  and  the 
operator's  performance. 
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In  spite  of  these  technological  advances,  the  ability  of  the 
manipulators  to  perform  cost  effective  work  was  generally  poor. 
The  primary  reason  for  this  was  that  we  had  not  addressed  the 
work  tasks  that  the  manipulator  had  to  perform.  This  limitation 
in  the  ability  to  perform  work  restricted  the  depth  of  cost 
effective  oil  production  to  those  depths  where  divers  could 
intervene  if  necessary. 

The  same  limitation  could  very  easily  result  in  space,  and  like 
the  oil  industry,  the  commercialization  of  space  will  be  sup- 
pressed if  cost  effective  work  systems  are  not  developed. 

In  the  past  five  years  we  have  seen  an  enormous  expansion  in  the 
areas  of  equipment  design  interface  engineering  and  tele-operated 
tooling. 

We  now  work  very  closely  with  the  oil  companies  to  design  their 
equipment  for  serviceability.  This  work  typically  has  a minimal 
impact  on  the  overall  cost  of  the  equipment  but  increases  the 
performance  of  tele-operated  manipulators  by  orders  of  magnitude. 
Typically  this  work  includes: 

o defining  the  tasks  and  subtasks  down  to  specific  functions, 
degrees  of  freedom,  forces  and  torques, 
o defining  manipulator  work  envelopes  and  access  requirements, 
o establishing  docking  ports  and  alignment  guides, 
o establishing  visual  identification  and  reference  points, 
o developing  standardized  manipulator-to-equipment  interfaces, 
o developing  a variety  of  modular  tools  with  standardized 
manipulator-to-tool  interfaces. 

The  resulting  subsea  equipment  is  then  not  only  easier  to 
service  with  tele-robotic  systems  but  is  proportionally  easier 
to  service  with  hyperbaric  divers  and  atmospheric  diving  suits 
with  end-effectors.  The  same  analogy  would  apply  to  astronauts 
using  gloves  and  mechanical  end-effectors. 

This  design  process  has  significantly  reduced  the  costs  of 
supporting  deepwater  drilling  and  production  and  has  resulted  in 
cost  effective  drilling  operations  in  7500  fsw  and  sophisticated 
subsea  production  facilities  in  1500-2000  fsw.  This  was  not 
thought  possible  in  the  seventies,  even  though  the  manipulator 
technology  existed.  These  cost  savings  have  been  documented  in 
numerous  case  studies  which  show  between  five  hundred  and  several 
thousand  percent  cost  savings  over  a two-year  period. 

Clearly,  the  same  type  of  design  process  is  applicable  to  space 
operations.  This  does  not  mean  that  a premium  should  not  be 
placed  on  developing  and  expanding  robotic  technology.  Quite 
the  opposite  is  true.  Defined  spatial  orientations,  tasks,  and 
interfaces  provide  the  basis  for  implementing  a number  of 
robotic  technologies,  including  machine  vision  systems,  advanced 
control  systems  and  sensors,  knowledge  based  artificial  intelli- 
gence systems  and  a variety  of  advanced  robotic  tools.  All  of 
which  can  be  designed  to  address  multiple  tasks  on  a modular 
basis. 
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Without  this  type  of  design  process,  implementation  of  advanced 
robotics  will  be  suppressed  because  when  the  relationship 
between  the  work  task  and  work  system  is  changing  in  an  undefined 
manner  it  is  at  best  difficult  to  coordinate  and  at  worst  almost 
impossible. 

Sustaining  Engineering  Concepts 

Deepwater  production  equipment  is  installed  with  a 30  year 
operating  life  in  mind.  Certain  elements  of  the  subsea  equipment 
can  be  recovered,  at  a very  high  cost,  whereas  other  elements 
will  remain  on  the  seabed  throughout  the  life  of  the  field  and 
must  be  inspected,  maintained,  and  repaired  in  situ.  Failure  is 
permanent  unless  replacement/repair  was  addressed  at  the  outset 
of  the  planning  process.  This  area  is  actively  addressed  because 
of  the  economic  implications  of  lost  production,  pollution,  etc. 
There  are  two  phases  to  long  term  IMR  (Sustaining  Engineering)  : 
Preservice  and  Inservice. 

Preservice:  This  phase  calls  for  the  complete,  in  excruiating 
detail,  examination  of  the  equipment,  life  cycles,  inspection 
needs,  maintenance  requirements,  and  repair  criteria.  This  falls 
under  Development  Engineering  and  incorporates  historical  data, 
analytical  input,  field  service  input,  manufacturer's  data,  and 
experience.  From  this  examination,  long  term  IMR  specifications 
can  be  developed  that  address  the  total  range  of  support  that  the 
equipment  will  require  throughout  its  operating  life. 

The  IMR  specifications  are  combined  with  the  input  from  the 
Maintenance  Engineering  for  the  Development  of  the  IMR  System 
which  includes  a database  program  supporting  a 30  year  program 
broken  into  five-year  and  one-year  cycles  . The  database  is 
developed  such  that  annual  IMR  requirements  can  be  modified  in 
real  time  by  incorporating  future  requirements  based  on  the 
results  of  an  ongoing  inspection. 

The  definition  of  work  task  requirements  is  carried  out  to 
insure  that  all  the  necessary  work  tasks  required  to  form  the 
long  term  IMR  have  been  defined.  This  phase  takes  into  account 
all  of  the  various  types  of  equipment  and  the  work  tasks  that  are 
associated  with  each  individual  item  of  equipment.  This  leads  to 
the  definition  of  the  maintenance  and  repair  procedures  which  is 
also  dependent  on  the  development  of  the  IMR  system  itself.  The 
maintenance  and  repair  procedures  are  laid  down  as  a subset  of 
the  work  task  requirements  such  that  the  method  and  equipment 
required  to  execute  the  work  could  be  defined  and  analyzed  for 
flexibility,  cost  effectiveness,  and  reliability. 

Once  the  work  tasks  are  defined  it  is  essential  to  determine  the 
work  envelopes  and  functions  required.  This  is  critical  when 
dealing  with  procedures  to  be  performed  by  teleoperated  systems. 
Work  envelopes  and  functions  must  be  fully  analyzed  to  insure 
that  accessibility  of  both  a teleoperated  system  and  the  manipu- 
lator or  automated  tooling  system  is  compatible  with  the  items  to 
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be  inspected,  maintained,  and/or  repaired.  The  purpose  of  the 
work  envelope  and  function  analysis  is  not  only  to  prove  their 
appropriateness  but  to  attempt  to  reduce  the  number  of  work 
envelopes  and  functions  such  that  a reasonable  teleoperated 
system  is  capable  of  supporting  a wide  range  of  maintenance  and 
repair  procedures.  If  the  work  envelope  and  function  work 
is  carried  out  properly  the  amount  of  additional  tooling  and  the 
need  for  additional  teleoperated  systems  can  be  reduced  in 
number,  hopefully  to  one. 

It  is  also  in  this  phase  when  it  becomes  obvious  whether  a 
special  purpose  teleoperated  system  is  a more  effective  tool  than 
a more  generic  teleoperated  system  which  has  changeable  work 
packages.  Further  analysis  may  lead  to  the  point  where  manned 
intervention  is  a more  satisfactory  solution  than  the  teleoper- 
ated options  in  that  the  task  may  be  so  specialized  or  difficult 
that  it  is  not  reasonable  or  prudent  to  depend  on  a teleoperated 
system.  This  area  leads  to  the  selection  of  the  best  system  to 
carry  out  long  term  IMR  work  on  the  equipment  and  also  insures 
that  the  minimum  number  of  systems  are  required  to  carry  out  the 
full  range  of  IMR  tasks.  The  selection  of  the  proper  work 
system  is  fundamental  to  long  term,  cost  effective  maintenance 
of  the  subsea  production  facilities. 

Subsequent  to  this  it  is  necessary  to  address  the  interface 
engineering  on  the  equipment  itself  to  'insure  that  it  is 
compatible  with  the  work  systems  which  will  be  carrying  out  the 
IMR  work.  Again,  the  driving  force  is  to  come  up  with  standard- 
ized interfaces  such  that  the  teleoperated  system  does  not 
require  a wide  range  of  interchangeable  tooling  or  manipulator 
end  effectors  to  perform  the  necessary  work.  Over  the  years  it 
has  been  shown  that  the  work  can  be  carried  out  by  a minimum 
number  of  end  effectors  and  tools  if  interface  engineering  is 
carried  out  in  a disciplined  and  analytical  method.  This  leads 
to  the  design  of  the  actual  tooling,  mocking  up,  and  testing  to 
verify  that  the  end  effectors  and  tools  are  compatible  with 
the  interface  engineering  which  is  being  carried  out  on  the 
subsea  equipment.  This  is  followed  by  final  testing  and  accept- 
ance prior  to  service. 

Inservice:  Development  of  the  30-year  IMR  program  in  conjunction 
with  the  definition  and  selection  of  the  appropriate  procedures, 
work  system  and  interface  engineering  results  in  cost  savings 
that  exceed  50  times  the  cost  of  the  front  end  work  under  normal 
circumstances.  More  importantly,  it  guarantees  that  the  systems 
will  continue  to  function  and  produce  throughout  the  3 0-year 
life  of  the  program.  As  deepwater  development  costs  are  ap- 
proaching one  billion  dollars  for  individual  projects  and  the 
value  of  production  is  several  times  that,  there  is  an  overriding 
consideration  for  executing  this  front  end  work  in  a thorough, 
timely,  and  quantifiable  manner.  A great  deal  of  design  and 
testing  makes  up  this  front  end  (preservice)  effort.  Each 
project  adds  significantly  to  the  existing  database.  At  present 
there  are  six  major  developments  in  deepwater  that  are  totally 
dependent  on  long  term  support  by  teleoperated  systems. 
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The  inservice  aspect  of  IMR  is  the  actual  long  term  operational 
support  of  the  subsea  equipment.  This  is  where  the  routine  work 
defined  by  the  30  year  program  is  carried  out  in  accordance 
with  the  prescribed  program  and  with  changes  that  are  generated 
with  time.  In  addition  it  is  in  this  phase  where  we  deal  with 
failures,  faults,  or  inadequate  performance.  The  following 
section  will  describe  the  general  steps  taken  when  a failure, 
fault,  or  inadequate  performance  is  noted  and  methods  taken  to 
address  and  correct  the  deficiency.  The  first  aspect  is  that 
information  is  immediately  fed  to  safety  to  determine  if  there  is 
a safety  related  problem  and  what  interim  requirements  should  be 
implemented  during  the  time  it  takes  to  upgrade  the  performance. 
The  safety  group's  decisions  cannot  be  negated  by  any  other 
group  without  a formal  review  process.  This  ensures  that  short 
term  decisions  cannot  hamper  the  decisions  of  safety.  At  the 
same  time  the  original  design  engineering  is  informed  through  an 
equipment  failure  notification  process.  Engineering  in  this  case 
denotes  both  the  inhouse  and  the  equipment  manufacturer's  groups 
- if  they  are  a separate  organization.  The  steps  which  follow 
are  similar  in  both  organizations  and  are  carried  out  in  parallel 
with  the  informational  results  being  exchanged  at  each  step  along 
the  way.  This  insures  that  there  is  both  a checks  and  balances 
and  that  nothing  is  left  unaddressed  due  to  oversight  on  either 
the  two  groups. 

The  engineering  groups  will  carry  out  a detailed  design  analysis 
review  to  insure  that  the  system  as  designed,  met  the  specifica- 
tions and  the  life  cycles  required  of  it.  The  determination  of 
failure  will  be  made  to  determine  exactly  what  component  or  part 
has  failed,  what  the  method  of  failure  was,  and  whether  it  would 
appear  to  be  a random  failure  or  a failure  based  on  the  life 
cycle  and/or  loading  requirements  imposed  upon  the  equipment. 

Once  this  phase  is  completed  a new  prototype  will  be  defined, 
designed,  and  developed.  It  will  then  go  through  a series  of 
verification  phases  the  first  of  which  being  a materials  test  to 
insure  that  the  new  materials  are  appropriate  and  provide 
satisfactory  results  for  the  long  term  solution  to  the  problem. 
The  materials  test  verification  phase  leads  to  a functional  test 
verification  where  an  item  is  put  through  the  full  range  of 
functional  tests  to  verify  that  it  satisfies  the  new  specifica- 
tion generated  for  it  and  is  capble  of  performing  the  work 
required. 

After  the  functional  test  has  been  verified  the  equipment  is 
tested  to  show  that  it  can  replace,  exchange,  and  interface  with 
existing  hardware.  A long  term  life  cyclic  verification  is 
carried  out  to  satisfy  the  engineering  group  that  the  new  life 
cycle  requirements  are  being  met.  This  leads  to  final  engineer- 
ing acceptance  testing  at  which  time  the  equipment  is  put  into 
the  field  engineering  group  and  the  installation  procedures  are 
developed  in  conjunction  with  engineering. 
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Safety  is  involved  throughout  the  process  to  insure  that  the 
safety  requirements  are  being  addressed  and  satisfied  at  each 
step  of  the  program.  The  procedures  go  through  an  operational 
review  process  to  insure  that  they  are  compatible  with  both  the 
existing  system,  the  equipment  and  personnel  available  to  carry 
out  the  work,  and  the  long  term  operational  support  of  that 
particular  item.  Field  installation  is  carried  out  in  conjunc- 
tion with  engineering  and  field  service  engineering  and  after  the 
equipment  is  fully  installed  and  tested  there  is  a final  field 
acceptance  test  carried  out.  At  this  time  the  equipment  is  turned 
over  to  the  long  term  operating  group. 

The  preservice  and  inservice  engineering  of  subsea  equipment  has 
become  the  most  important  aspect  of  deep  water  development.  The 
fact  that  equipment  placed  in  deep  water  can  neither  be  accessed 
nor  recovered  through  conventional  means  throughout  the  30  year 
life  of  the  program  means  that  the  design,  interface,  and  remote 
work  support  systems  that  will  be  needed  to  insure  the  30  year 
operating  performance  of  the  equipment  needs  to  be  carefully 
addressed  at  the  outset.  History  has  shown  that  the  degree  of 
effort  placed  into  the  upfront  engineering  involved  in  this 
entire  program  is  recovered  many  times  over  throughout  the  life 
of  the  project.  Failure  to  address  any  one  detail  in  sufficient 
degree  to  insure  its  compatibility  with  the  system  can  lead  to 
the  total  shutting  in  of  a reservoir  and  the  loss  of  production. 
The  implications  of  this  from  an  economic  point  of  view  are 
extremely  severe.  In  addition  failures  that  could  effect  safety 
have  implications  every  bit  as  severe.  Deep  water  production 
systems  have  the  unforgiving  element  in  that  they  can  never  be 
retrieved,  repaired,  and  inspected  by  conventional  methods.  All 
this  work  must  be  done  remotely  through  the  use  of  predesigned, 
pre-engineered  equipment.  Many  years  of  experience  in  carrying 
this  work  out  in  shallow  water  with  divers  has  provided  the  basis 
which  has  allowed  the  production  systems  installed  in  deep  water 
to  be  supported  successfully  to  date.  Each  project  gains  consi- 
derable knowledge  from  the  experience  of  prior  projects  and  the 
cost  effectiveness  of  each  solution  continues  to  grow  as  develop- 
ments occur. 
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The  requirement  for  subsea  work 
capabilities  to  support  offshore  oil 
production  in  increasing  water  depths 
has  led  to  the  evolution  and  develop- 
ment of  a variety  of  work  systems. 
These  work  systems  range  from  hands- 
on  divers  to  manned  atmospheric 
diving  suits  with  end  effectors  and  a 
variety  of  tele-operated  manipulator 
work  systems. 

Selection  of  the  optimum  work 
system  to  perform  an  operation  de- 
pends on  the  work  task  requirements , 
the  environmental  conditions , physio- 
logical limitations , logistical  re- 
quirements and  economic  considera- 
tions. Hie  resulting  selection  may 
be  a single  work  system  with  special 
modifications  or  a combination  of 
work  systems  exploiting  the  strong 
points  of  each. 

Hie  commercial  diving  industry 
has  more  than  twenty- five  years  ex- 
perience in  work  systems  development 
resulting  in  several  million  hours  of 
underwater  operations. 

This  paper  will  briefly  overview 
the  working  environment , physiologic- 
al limitations,  work  task  require- 
ments and  work  systems  in  the  subsea 
industry. 


WORKING  KNVIRONMEMT 

Hie  commercial  underwater  work- 
ing environment  to  date  is  character- 
ized by  the  following  parameters: 

• pressure:  0-3350  psi  (0-7500  ft) 

e temperature:  32-92°  F 

• visibility:  0-200  ft 

• waves:  0-30  ft 

e currents:  0-4  kts 

In  many  respects,  the  underwater 
environment  is  a more  hostile  envir- 
onment to  work  in  than  outer  space. 
Hi  is  is  particularly  true  with  re- 
spect to  visibility  and  current/wave 
forces.  The  underwater  environment 
is  also  dynamic  and  capable  of  radic- 
al changes  over  short  time  periods, 
imposing  greater  operating  ranges  on 
the  work  systems. 

PHYSIOLOGICAL  LIMITATIONS 

Hie  main  physiological  limita- 
tions are  summarized  as  follows: 

Decompression  - After  working  under- 
water at  increased  pressures,  divers 
must  undergo  a gradual  decompression 
to  sea  level  to  avoid  the  bends. 
This  decompression  time  can  range 
from  minutes  to  days,  depending  on 
the  depth  and  duration  of  the  dive. 

Inert  Gas  Narcosis  - For  air  diving 
below  approximately  150  ft,  the  in- 
creased partial  pressure  of  nitrogen 
creates  a narcotic  effect  on  the  cen- 
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tral  nervous  system.  To  eliminate 
this  effect,  helium/oxygen  (heliox) 
breathing  mixes  are  used  for  deeper 
dives. 

High-Pressure  Nervous  System  - HPNS 
is  associated  with  rapid  compression 
on  heliox  to  deeper  depths.  It  can 
cause  dizziness,  disorientation  and 
mild  convulsions. 

Gas  Toxicity  - Oxygen  and  carbon  di- 
oxide toxicity  are  critical  and  must 
be  carefully  controlled  during  diving 
operations. 

Thermal  Limitations  - Temperature  and 
humidity  must  be  maintained  within 
narrow  limits,  particularly  with  the 
greater  heat  capacity  of  heliox 
breathing  mixtures. 

DORK  TASK  KBQPIKEMBHTS 

The  work  task  requirements  can 
be  broken  down  into  the  following 
phases  relative  to  the  evolution  of  a 
producing  oil  field. 

• Drilling  Support 

• Construction  & Maintenance 

• Inspection 

• Repair 

Drilling  Suport  - The  work  require- 
ments for  this  phase  are  primarily 
related  to  the  installation,  observa- 
tion, maintenance  and  recovery  of  the 
subsea  blowout  preventer  and  associ- 
ated equipment. 

Die  basic  work  tasks  are  simple 
attachments , observations , vertical 
alignments,  valve  actuation,  debris 
removal  and  changeouts  of  hydraulic 
hoses,  electrical  cables,  connectors 
and  modules. 


typical  Subsea  Blowout  Preventer 

Construction  - This  phase  is  primar- 
ily involved  in  the  installation  and 
hookup  of  offshore  platforms  and 
pipelines.  The  platforms  are  typi- 
cally fabricated  onshore  and  then 
towed  to  the  offshore  location. 

Die  work  task  requirements  in 
the  construction  phase  involve  com- 
plex rigging  and  alignments,  assemb- 
ling mechanical  connectors,  burning, 
welding,  water  jetting,  special  tool- 
ing and  frequently  onsite  fabrication 
and  modifications. 
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Inspection  - The  work  requirements 
for  inspection  are  primarily  involved 
with  the  cleaning  and  inspection  of 
in-service  platforms  and  pipelines. 

The  work  tasks  required  are  ob- 
servation, water  jetting,  cleaning 
with  power  tools,  closeup  photog- 
raphy, detailed  measurements  and  non- 
destructive testing. 

Repair  - The  work  requirements  for 
repair  are  primarily  involved  with 
mechanical  and  hyperbaric  welded 
structural  repairs  of  platforms  and 
pipelines. 

The  work  task  requirements  as- 
sociated with  repairs  are  detailed 
measurements,  complex  rigging  and  al- 
ignments, burning,  welding,  special 
tool  operation  and  on-site  fabrica- 
tion and  modifications. 
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WORK  SYSTEMS 

This  section  will  overview  the 
various  types  of  work  systems.  These 
work  systems  can  be  classified  as 
follows : 

• Hyperbaric  Diving 

• Atmospheric  Work  Systems  (Manned) 

• Tele-Operated  Work  Systems 

• Hybrid  Systems 

Where  applicable,  each  type  of  work 
system  will  be  outlined  in  the  fol- 
lowing format: 

• Work  Capabilities 

• Special  Interface  Requirements 

• Limitations 

HYPERBARIC  DIVING 

Hyperbaric  diving  involves  div- 
ers working  in  an  ambient  pressure, 
■hands-on"  environment.  In  order  to 
work  at  ambient  pressures,  high-pres- 
sure breathing  gases  must  be  inspired 
to  maintain  a pressure  equilibrium 
across  the  lungs.  This  leads  to 
tissue  absorption  of  inert  gases  and 
a decompression  requirement.  Diving 
can  be  classified  into  three  types 
with  respect  to  decompression: 

Surface  Diving  - For  surface  diving, 
divers  will  descend  to  depth,  perform 
a task  within  a limited  amount  of 
bottom  time,  and  then  decompress  back 
to  the  surface  in  accordance  with  a 
predetermined  decompression  sched- 
ule. This  type  of  diving  applies  up 
to  depth  of  300  ft. 

Bell  Bounce  Diving  - For  bell  bounce 
diving,  divers  will  descend  to  depth 
(300-600  ft)  in  a diving  bell  at  one 
atmosphere.  After  analyzing  the  job 
requirements,  the  bell  is  rapidly 
compressed  to  ambient  pressure,  at 
which  point  the  divers  lock  out  and 
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perform  the  work  task  within  a limit- 
ed excursion  time. 

After  completing  the  job,  the 
diver  returns  to  the  bell  and  makes  a 
pressure  seal.  The  bell  is  then 
brought  to  the  surface  and  mated  to  a 
deck  decompression  chamber,  where  the 
diver  completes  the  decompression  re- 
quirement. The  principal  limitation 
with  this  type  of  diving  is  the  low 
working  time  to  decompression  time 
ratio.  For  30  minutes  bottom  time  at 
500  ft,  approximately  28  hours  decom- 
pression is  required.  If  a job  re- 
quires long  bottom  times,  then  satu- 
ration diving  will  be  used. 

Saturation  Diving  - For  saturation 
diving,  the  divers  will  remain  at  a 
pressure  equivalent  to  their  working 
depth  for  up  to  40  days.  Once  the 
body  is  saturated  with  inert  gas  at  a 
given  depth  (approximately  8 hours) , 
then  the  decompression  requirement  is 
fixed,  regardless  of  the  time  spent 
at  that  depth. 

Saturation  diving  requires  the 
use  of  a special  modular  diving  sys- 
tem made  up  of  the  following  compon- 
ents: 

Diving  Bell:  The  diving  bell  is  a 
pressure  vessel  designed  to  be  mated 
to  a deck  decompression  complex , al- 
lowing diver  transfer  under  pressure 
between  the  deck  complex  and  the 
worksite. 

Deck  Decompression  Complex:  The  deck 
decompression  complex  consists  of  two 
or  more  pressure  vessels,  the  primary 
purpose  of  which  is  to  provide  safe 
living  quarters  for  the  divers  while 
under  pressure  between  working  dives, 
or  decompressing  upon  couplet  ion  of 
the  job.  As  the  deck  chambers  are 
modular,  any  number  can  be  bolted  to- 
gether to  accommodate  various  crew 
sizes. 


Control  Van:  Power,  communications, 
gas  control,  gas  monitoring  and  en- 
vironmental control  for  the  deck  com- 
plex and  the  diving  bell  are  all 
housed  in  a single  control  van.  The 
life  support  systems  are  all  modular 
so  that  in  an  emergency,  any  pressure 
vessel  of  the  system  can  be  isolated. 
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Control  Van  Showing  Nodular  Life- 
Support  Control  Panels 

Work  Capabilities 

Hyperbaric  diving,  because  of 
human  perception,  judgment  and  dex- 
terity, provides  the  most  complete 
and  versatile  work  system  in  the  sub- 
sea industry.  Divers  were  the  orig- 
inal work  system  and  have  performed 
efficiently  all  of  the  underwater 
tasks  required  for  offshore  oil  pro- 
duction. ttiis  baseline  experience 
with  man  has  provided  the  knowledge 
required  to  design  alternate  work 
systems,  some  of  which  can  perform 
certain  tasks  more  effectively  than 
man. 

Special  Interface  Requirements 

Special  man/equipment  interfaces 
are  usually  not  provided.  typical 
offshore  structures  are  constructed 
from  tubular  trusses  from  10  to  36 
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in.  diameter,  nils  makes  it  possible 
to  attach  to  the  structure  in  a vari- 
ety of  body  positions  using  arms  and/ 
or  legs.  On  larger-diameter  tubu- 
lars, work  restraint  stations  are 
fashioned  from  rope  tethers  and  other 
items  of  opportunity. 

Occasionally,  on  special  pro- 
jects, diver  work  stations  are  de- 
signed into  the  structure  at  key  lo- 
cations. This  approach  has  proved  to 
be  cost-effective  but  tends  to  be  the 
exception. 

Limitations 

The  following  are  some  of  the 
limitations  associated  with  hyperbar- 
ic diving: 

e Human  safety 

• Depth  limitations 

e Dive  duration  limitations 
e Decompression  penalties 
e Support  crew  and  space  requirements 

# Reduced  accessibility  to  hazardous 
areas 


Diver  Using  an  Impact  Wrench  to 
Tighten  Bolts  on  a Riser  Clamp. 
Note  Dse  of  Legs  as  Attachment  Point 


Diver  Attaching  Come- Along  to  Secure 
Underwater  Welding  Habitat 

ATMOSPHERIC  WORK  SYSTEMS  (AWS) 

Atmospheric  work  systems  utilize 
man  in  a one-atmosphere  shirtsleeve 
environment  and  can  be  subdivided  in- 
to atmospheric  diving  suits  (ADS) 
with  end-effectors,  and  manned  sub- 
mersibles  with  manipulators. 

Atmospheric  Diving  Suits  (ADS) 

JIM:  JIM  is  an  atmospheric  diving 

suit  with  articulated  arms  and  legs, 
the  limbs  being  neutrally  buoyant  so 
that  operator  effort  is  only  required 
to  overcome  the  friction  of  the  ar- 
ticulated pressure  balanced  joints. 
The  JIM  suit  receives  no  power  from 
the  surface  with  its  lift  umbilical 
containing  only  a communications 
cable. 


Life  support  up  to  72  hours  is 
provided  through  onboard  oxygen  bot- 
tles. Since  the  suit  does  not  leak, 
the  nitrogen  initially  in  the  suit 
serves  as  a dilutant  inert  gas 


throughout  the  dive,  eliminating  the 
requirement  for  a two-gas  life  sup- 
port system.  Carbon  dioxide  removal 
is  provided  through  an  oral-nasal 
lung-powered  scrubber. 

The  end-effector  assemblies  work 
via  a through-hull  solid  shaft  pene- 
tration operated  by  the  hand  motions 
of  the  pilot.  Otoey  can  be  continuous- 
ly rotated  in  either  direction  and 
locked  in  position.  The  end-effec- 
tors have  standardized  grip  surfaces 
and  a rope  hook  used  for  sliding  down 
guidewires.  These  end-effectors  are 
able  to  interface  with  pre-engineered 
tools  and  work  stations  and  have  re- 
mained essentially  unchanged  through- 
out the  entire  commercial  life  of  the 
suit. 


JIM  Working  on  Subsea  Wellhead 


WASP:  Hie  WASP  is  a free-flying  at- 
mospheric diving  suit  which  utilizes 
the  same  articulated  arms  as  JIM,  but 
has  no  legs.  The  WASP  receives  power 
and  communications  through  an  umbili- 
cal to  the  surface.  Translation  and 
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station-keeping  are  provided  through 
four  foot-controlled  thrusters. 

Life  support  iB  provided  by  an 
oxygen  makeup  system  similar  to  JIM; 
however,  fan-powered  scrubbers  are 
used  for  carbon  dioxide  removal. 

Work  Capabilities  - Hie  JIM  suit  is 
used  primarily  on  drilling  support. 
It  has  successfully  performed  inspec- 
tions, attachments,  debris  removal, 
replaced  valve  assemblies  and  other 
tasks  associated  with  drilling  sup- 
port. 

Tasks  performed  with  JIM  require 
interface  engineering  between  the 
end-effectors  and  the  equipment,  and 
typically  require  a longer  time  than 
a hyperbaric  diver. 

The  WASP  has  similar  capabili- 
ties to  JIM  with  respect  to  drilling 
support.  It  can  also  be  used  for 
mid-water  work  such  as  general  plat- 
form inspection,  cathodic  protection 
measurements,  waterblasting  and  other 
simple  manipulative  work  tasks. 

The  WASP  has  been  used  success- 
fully on  some  specially- inter faced 
midwater  construction  and  repair  pro- 
jects such  as  mechanical  clamp  and 
anode  installations. 


JIM  Operating  a Lifting  Jack 
Using  Both  End-Effectors 


WASP  Performing  Platform 
Inspection 


Special  Interface  Requirements 

JIM  needs  a pre-installed  walk 
deck  to  translate  around  the  subsea 
equipment.  Due  to  the  limited  abili- 
ty to  translate  the  bulk  of  the  suit, 
and  anthropomorphic  limbs  length  lim- 
itations, some  of  the  subsea  equip- 
ment must  be  extended  to  JlM's  work 
envelope.  Die  equipment  must  also  be 
designed  for  interfacing  with  the 
jaws  of  the  end-effector.  There  are 
a variety  of  hand  tools  used  by  the 
JIM,  each  having  a standardized  end- 
effector  interface,  allowing  multiple 
tools  to  be  used  without  changing  the 
end-effectors. 

The  WASP  requires  standardized 
equipment  and  tool  interfaces  similar 
to  JIM.  Also,  depending  on  the  job, 
special  work-restraint  systems  and 
equipment  extensions  are  utilized. 
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Limitations 

• Human  safety 

• Depth 

• Dive  duration 

• Reduced  accessibility/work  envel- 
opes 

• Restricted  to  bottom  work  (JIM) 

• Stationkeeping  when  performing  cer- 
tain tasks  in  free-flying  mode 
(HASP)  . 

MANNED  SUBMERSIBLES  WITH  MANIPULATORS 
ARMS  Bell 

The  ARMS  bell  has  an  interior 
maintained  at  one  atmosphere,  and  is 
designed  to  support  a two-man  crew 
for  6 hours  mission  time  plus  84 
hours  reserve.  Observation  of  the 
work  site  is  provided  through  a wide- 
angle  plexiglass  viewport.  The  bell 
is  equipped  with  thrusters  to  provide 
lateral  translational  capabilities 
about  the  worksite. 


ARMS  Bell 


The  ARMS  Bell  will  have  up  to 
three  manipulators.  The  manipulator 
in  the  center  of  the  bell  has  two  de- 
grees of  freedom  and  typically  is 
used  as  a work  restraint  system.  On 
the  left  and  right  are  either  two 
seven-function  manipulators  or  a 
seven-  and  five-function  manipulator. 
The  manipulators  have  standardized 
locking  jaw  end-effectors.  Typical- 
ly , the  five-function  manipulator  is 
used  as  a grabber  to  initially  align 
the  work  task,  while  the  seven-func- 
tion (six  degrees  of  freedom)  manipu- 
lator performs  the  dextrous  work 
task.  The  five-  and  seven-function 
manipulators  are  usually  spatially 
correspondent,  utilizing  a master/ 
slave  relationship.  The  work  re- 
straint maniuplator  is  typically  rate 
feed. 

On  some  submersibles , the  seven- 
function  manipulator  is  equipped  with 
force  feedback,  greatly  enhancing  the 
work  capabilities. 

Typically,  the  manipulators  are 
used  only  one  at  a time  for  the  fol- 
lowing reasons : 

• In  order  to  effectively  use  two 
manipulators  simultaneously,  both 
must  have  force  feedback  and  dynamic 
conpliance  in  order  to  optimize  the 
resultant  force  vectors. 

e Most  jobs  do  not  justify  the  ex- 
pense of  two  force-feedback  manipu- 
lators and  can  be  performed  using  the 
various  manipulators  sequentially. 

• Operator  demands  are  greater. 
This  is  particularly  true  in  the 
tele-operated  systems  where  spatial 
perception  is  restricted  by  camera 
viewing  angles  and  the  inability  of 
pan-and-tilt  mechanisms  to  scan  as 
quickly  as  the  human  eye. 
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In  addition  to  the  ASMS  Bells, 
there  are  a variety  of  one-manned 
tethered  submersibles  with  similar 
manipulator  arrangements  and  work 
capabilities.  These  include  the  Man- 
tis, Wrangler  and  an  untethered  ver- 
sion of  the  Deep  Rover. 

Work  Capabilities 

The  human  in  a comfortable 
shirtsleeve  environment  provides  high 
visual  awareness  and  interpretive 
capability.  With  longer  manipulators, 
these  systems  have  a greater  working 
envelope  than  the  ADS  suits,  whose 
work  envelopes  are  limited  by  anthro- 
pomorphic limbs.  These  capabilities 
have  combined  to  produce  an  excellent 
track  record  in  performing  all  the 
work  tasks  associated  with  drilling 
support.  Because  of  size,  transla- 
tional capabilities  and  mobilization 
requirements,  these  systems  are  not 
frequently  used  in  the  other  work 
phases . 


ARMS  Bell  Aligning  a Shackle  Pin 


Special  Interface  Requirements 

e Standardized  end-effector/equipment 
interface  similar  to  the  ADS  suits 
e Work  restraint  attachment  points 

Limitations 

e Human  safety 
e Depth  limitations 
e Dive  duration  limitations 
e Increased  size,  space,  crew 
e Reduced  accessibility  and  transla- 
tional capabilities 

TELE-OPERATED  WORK  SYSTEMS 

Tele-operated  work  systems  are 
controlled  by  humans  viewing  televis- 
ion monitors  remote  from  the  work- 
site. The  various  types  of  systems 
can  be  classified  as  follows: 

e Inspection  Vehicles 
e Light  Work  Vehicles 
e General-Purpose  Pull  Work  Vehicles 
e Modular  Work  Vehicles 
e Special-Purpose  Vehicles/Machines 

INSPECTION  VEHICLES 

This  class  of  tele-operated  work 
system  consists  of  a variety  of 
small,  tethered,  remote-controlled, 
self-p rope lied  observation  vehicles. 
They  have  onboard  video  cameras  typi- 
cally mounted  on  a pan-and-tilt  mech- 
anism. This,  combined  with  superior 
mobility,  allows  the  inspection  vehi- 
cle to  observe  underwater  operations 
from  a variety  of  orientations  and  in 
confined  areas. 
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Inspection  Vehicle 
Work  Capabilities 

These  vehicles  are  used  exten- 
sively throughout  all  phases  of  oil 
production.  In  drilling  support, 
they  serve  as  flying  eyeballs  to  al- 
low surface  crews  to  observe  the  un- 
derwater operation  of  subsea  equip- 
ment and  potentially  identify  or  pre- 
vent problems. 

In  construction,  they  are  used 
to  monitor  subsea  operations  and  to 
locate  and  pre-inspect  work  sites, 
allowing  the  divers  or  other  work 
systems  to  identify  and  plan  job  re- 
quirements prior  to  diving. 

For  platform  inspection,  they 
are  used  to  perform  the  general  visu- 
al inspection  of  the  platform.  In 
this  role,  they  can  be  more  effective 
than  hyperbaric  divers  because  of  su- 
perior translational  capabilities, 
depth- independent  operations  (within 
design  limits) , and  longer  dive  dura- 
tion capabilities.  They  also  produce 


a permanent,  annotated  video  documen- 
tation of  the  entire  inspection. 

For  platform  inspection,  typi- 
cally the  divers  will  be  performing 
the  detailed  cleaning  and  inspection 
work,  while  the  inspection  vehicle 
does  the  general  "flyby*  inspection. 
This  simultaneous  operation  reduces 
the  total  job  time  requirements. 
These  vehicles  are  also  used  to  moni- 
tor diver  performance  and  safety. 

Special  Interface  Requirements 

There  are  no  work  interface  re- 
quirements, as  these  vehicles  do  not 
have  manipulators.  On  some  subsea 
equipment,  location  reference  systems 
are  provided  to  orient  the  pilot. 

Limitations 

e Limited  visual  awareness 
e Low  interpretive  capability 
e No  manipulative  capabilities 
e Limited  payload  capabilities 
e Inadequate  real-time  response  to 
changing  environment 

LIGHT  WORK  VEHICLES 

This  class  of  vehicles  is  simi- 
lar to  the  inspection  vehicles;  how- 
ever , they  have  increased  payload 
capabilities  and  are  capable  of 
utilizing  small,  limited  manipulat- 
ors. 

Work  Capabilities 

These  vehicles  can  perform  the 
same  role  as  an  inspection  vehicle, 
with  some  loss  of  mobility  and  ac- 
cessibility. Additionally,  they  can 
carry  instrument  packages,  tools  and 
can  perform  very  simple  manipulative 
tasks,  such  as  attachments  and  place- 
ments. They  play  a bigger  role  in 
diver  support  in  that  they  are  cap a- 
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ble  of  transporting  tools  to  and  from 
the  diver  at  the  worksite . They  can 
also  be  used  as  a temporary  tool 
storage  platform. 


Interface  Requirements 

• Standardized  end-effector /equipment 
interface 

• Location  reference  systems  for  pi- 
lot orientation 


Limitations 


• Can  perform  only  simple  manipulat- 
ive tasks 

• Other  limitations  same  as  inspec- 
tion vehicle. 


GENERAL  PURPOSE  WORK  VEHICLES 


These  are  larger  vehicles  de- 
signed to  perform  manipulative  work. 
They  are  usually  equipped  with  a 
five-function  and  seven-function 
spatially  correspondent  manipulat- 
ors. These  manipulators  utilize  a 
master/slave  control  with  the  speed 
of  the  slave  proportional  to  the 
master . In  some  cases , the  seven- 
function  manipulator  is  enhanced  with 
force  feedback  and  dynamic  compli- 
ance, which  allows  the  operator  to 
feel  imposed  loads.  This  capability 
greatly  increases  work  performance 
due  to  increased  sensitivity  and 
awareness  of  the  work  task. 


The  manipulators  are  typically 
used  sequentially  with  the  five-func- 
tion initially  aligning  the  work 
task,  which  is  then  completed  using 
the  more  dextrous  seven-function  man- 
ipulator . 
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View  from  Manipulator-Mounted  Camera 
of  Work  Vehicle  on  Subsea 
Blowout  Preventer 

Work  Capabilities 

Although  vehicles  of  this  type 
are  used  in  all  phases  of  oilfield 
production,  their  primary  application 
is  in  drilling  support.  The  main 
reason  for  this  is  that  most  of  the 
required  tasks  and  sub tasks  have  been 
well  defined  and  are  capable  of  being 
reduced  to  exactly  the  functions  per- 
formed optimally  by  manipulators. 

General  purpose  work  vehicles 
are  also  used  in  construction  for  ob- 
servation, diver  support  and  pre-de- 
fined  work  tasks. 

Interface  Requirements 

• Standardized  manipulator/equipment 
interfaces 

• Work  restraint  attachment  points 
e Location  references 
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Limitations 


Interface  Requirements 


• Limited  visual  awareness  due  to  re- 
stricted camera  viewing  angles,  in- 
adequate scanning  capabilities  of 
pan-and-tilt  mechanisms,  and  surf- 
ace viewing  monitor  limitations 

• Low  interpretive  capability 

e Inadequate  real-time  response  to 
changing  environments 

• Limited  manipulative  capability 
compared  to  the  human  hand 

e Requirement  for  standardized  manip- 
ulator/equipment interfaces 
e Generally  inflexible  to  unpredicted 
changes 

MODULAR  WORK  VEHICLES 

Modular  work  vehicles  consist  of 
a basic  vehicle  that  provides  propul- 
sion, telemetry  and  control.  The 
basic  vehicle  is  capable  of  carrying, 
controlling  and  operating  a number  of 
special  work  packages  that  address 
specific  tasks.  Modular  work  vehi- 
cles are  large  systems  with  excess 
power  and  control  functions  in  order 
to  accommodate  a number  of  add-on 
packages,  including  contingencies  for 
future  expansion. 

Work  Capabilities 

ttie  modular  work  vehicle's  capa- 
bilities are  based  on  the  propulsion 
and  control  characteristics  available 
on  the  basic  vehicle.  The  work  pack- 
ages can  be  tailored  to  drilling  ac- 
tivities, as  well  as  support,  inspec- 
tion and  maintenance  taks.  The  suc- 
cess of  the  modular  work  vehicle  is 
dependent  on  the  functional  specifi- 
cations and  the  tradeoffs  of  a wide 
range  of  requirements  within  a single 
basic  vehicle.  If  necessary,  oppos- 
ing requirements  can  be  eliminated 
from  the  basic  unit  by  incorporating 
their  characteristics  within  the  work 
package  itself. 


• Same  as  General  Purpose  Pull  Work 
Vehicle. 

Limitations 

• Basic  unit  size  and  complexity  in- 
creased to  support  range  of  work 
packages 

e Accessibility  limitations  due  to 
overall  system  size 

• Other  limitations  same  as  General 
Purpose  Full  Work  Vehicle 


Typical  Modular  Work  Vehicle 
with  Force  Feedback  Arm 


SPECIAL-PURPOSE  WORK  SYSTEMS 

These  units  are  designed  from 
the  outset  to  carry  out  a specific 
set  of  tasks.  Ihe  power,  telemetry, 
configuration,  manipulation,  tooling, 
etc.  are  selected  and/or  developed  to 
support  the  defined  scope  of  work. 
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Special  purpose  systems  are  ex- 
tremely effective  in  carrying  out  the 
required  work , and  represent  a highly 
productive  and  reliable  method  of 
performing  work.  Two  examples  of 
special  purpose  vehicles  are  DYNA- 
CLAMP  and  RIG  BANDIT. 

Dynaclamp:  The  DYNACLAMP  is  a spec- 
ial purpose  machine  designed  to  carry 
out  the  cleaning , photographing  and 
detailed  inspection  of  the  welds 
found  at  the  nodal  joints  of  tubular 
members.  Ibis  highly  complex  work 
inposes  constraints  on  accessibility, 
viewing,  orientation  and  precise  man- 
ipulator functions  that  cannot  be  ad- 
dressed by  standard  systems,  The  DY- 
NACLAMP consists  of  a special  clamp 
with  a rotary  platform  holding  twin 
manipulators,  cameras,'  cleaning  heads 
and  telemetry /control  components  sup- 
ported by  its  own  umbilical.  DYNA- 
CLAMP is  delivered  to  the  worksite  by 
diver,  ADS  or  ROV,  greatly  expanding 
their  work  capabilities. 

Rig  Bandit:  The  RIG  BANDIT  is  a 
passive  work  system  designed  for 
guidewire-supported  drilling  support. 
The  RIG  BANDIT  consists  of  a frame 
holding  manipulators,  lighting  and 
cameras  that  is  attached  to  guidewire 
and  lowered  from  the  surface.  The 
RIG  BANDIT  can  be  clamped  to  the 
guidewires  at  the  working  depth  to 
provide  a stable  platform.  Ibis  con- 
figuration restricts  translational 
capabilities.  However,  the  system 
carries  out  certain  tasks  effectively 
with  a less  complex  system  than  would 
result  from  adaptation  of  a general- 
purpose  unit. 

HYBRID  WORK  SYSTEMS 

Operational  experience  with  the 
various  work  systems  has  led  to  suf- 
ficient understanding  of  their  work 
capabilities  to  allow  hybrid  work 


systems  to  be  designed.  Ibis  section 
will  briefly  describe  some  of  the  hy- 
brid work  systems  used  in  the  subsea 
industry. 

Mobile  Diving  Pnit  (MDP)  : The  MDU  is 
a combination  of  an  ARMS  manipulator 
bell  and  a saturation  diving  system. 
Ibis  combination  provides  the  crew 
member  the  opportunity  to  complete 
the  work  task  in  a one-atmosphere  en- 
vironment without  incurring  any  de- 
compression penalty. 

If  the  job  cannot  be  completed 
using  manipulators,  then  the  diver 
can  compress  the  bell  to  ambient 
pressure,  lock  out  and  perform  the 
task  in  a hands-on  environment. 

Mantis  Duplust  Ibis  vehicle  is  a 
combination  of  a manned  submersible 
with  manipulators  and  a tele-operated 
work  system.  It  can  be  used  in  eith- 
er the  manned  or  remote-operated 
mode,  depending  on  the  difficulty  of 
the  task  and  the  requirement  for  hu- 
man perception  and  judgment.  This 
type  of  system  has  the  secondary  ad- 
vantage of  allowing  the  submersible 
to  be  piloted  remotely  from  the  sur- 
face, while  the  crew  member  concen- 
trates on  the  manipulative  work  task. 

Dynaclamp:  The  DYNACLAMP  is  special- 
ly designed  for  performing  detailed 
cleaning,  inspection  and  maintenance 
tasks  in  restricted  nodal  areas.  For 
this  reason,  it  can  perform  these 
tasks  much  better  than  any  other  work 
system  except  possibly  hyperbaric 
divers. 

The  DYNACLAMP  can  be  delivered 
to  the  work  site  by  a general  purpose 
work  system  such  as  a WASP  or  general 
work  vehicle.  The  DYNACLAMP  then 
works  through  tele-operated  control, 
while  the  delivery  work  system  per- 
forms other , less  complicated  tasks 
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simultaneously.  This  combination 
greatly  extends  the  work  capabilities 
of  general-purpose  systems. 

DEEPWATER  PIPELINE  REPAIR  SYSTEMS 

The  deepwater  pipeline  repair 
system  is  a combination  of  a modular 
work  vehicle  and  a variety  of  special 
purpose  work  systems. 

This  system  was  designed  to  ad- 
dress one  major  task  - the  remote  re- 
pair of  deepwater  pipelines.  Within 
this  task  are  multiple  sub  tasks  that 
are  individually  addressed  by  special 
purpose  work  packages  which  are  in- 
terchangeable on  the  modular  work 
vehicle. 

The  integrated  system  can  carry 
out  a range  of  specific  inspection, 
installation  and  work  tasks,  includ- 
ing the  precision  alignment  of  mech- 
anical connectors,  the  lifting  and 
alignment  of  pipe  sections,  the  cut- 
ting and  bevelling  of  pipe  faces  and 
a number  of  measurement  tasks. 


Deepwater  Pipeline  Repair  System 
Showing  a Modular  Work  Vehicle 
Operating  a Pipeline  Alignment  Frame 
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The  system  uses  a combination  of 
sensors,  manipulators,  special  tools 
and  work  packages  to  carry  out  the 
designated  work. 

OPERATIONAL  PHILOSOPHIES 

Through  operational  experience, 
a number  of  very  clear  lessons  have 
been  learned.  Some  of  these  lessons 
are  as  follows: 

• Design  Beruipment  for  Intervention  - 
This  has  proven  to  be  cost-effective. 
The  6mall  increase  in  initial  cost  is 
paid  for  the  first  time  the  equipment 
breaks  down.  Triple-redundant  fail- 
proof  systems  cost  more  up  front  and 
more  to  repair  when  they  do  break 
down. 

• Standardize  End-Effector/Bguipment 
Interfaces  - This  can  make  pre-plan- 
ning and  job  execution  a lot  easier. 
It  is  also  a more  sensible  approach 
than  changing  end-effectors  for  each 
task  or  designing  complex  multi-fing- 
er end-effectors. 

• Design  Simple  Job  Requirements  - A 
job  can  be  done  in  a number  of  ways 
and  with  a variety  of  methods.  It  is 
important  not  to  over-engineer  the 
job. 

• Documentation  - Poor  documentation 
of  subsea  equipment  can  lead  to  inad- 
equate planning,  useless  tool  design 
and  ineffective  operations.  When 
possible,  equipment  should  be  docu- 
mented extensively  with  photographs 
and  scale  drawings. 

• Select  the  Most  Effective  Work  Sys- 
tem - A number  of  work  systems  may  be 
able  to  do  the  job,  but  how  produc- 
tive and  cost-effective?  In  select- 
ing the  optimum  work  system,  it  is 
important  to  start  at  the  task  and 
work  backwards  as  opposed  to  trying 
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to  fit  the  wrong  work  system  where  it 
does  not  apply. 

A sensible  approach  to  this  process 
is  as  follows: 

• Define  the  work  tasks 

• Determine  work  envelopes 

• Determine  required  functions 

• Incorporate  operational  considera- 
tions 

• Select/design  optimum  work  systems 

• Perform  interface  engineering 

e Design/manufacture  special  tooling 
e Perform  testing  and  optimization 

For  many  work  tasks,  the  answer 
may  be  hands-on  divers  or  gloved  as- 
tronauts. In  other  cases,  hybrid 
work  or  special-purpose  systems  would 
be  more  effective. 

CONCLOSIOHS 

The  evolution  of  work  systems  in 
the  subsea  industry  has  been  the  re- 
sult of  direct  operational  experience 
in  a competitive  market.  Hiis  exper- 
ience should  help  to  make  the  evolu- 
tion of  work  systems  more  efficient 
for  space  operations. 
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Vice  President,  Special  Projects 
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Over  the  past  several  years  divers 
and  remotely  operated  vehicles 
(ROVs)  have  become  increasingly 
more  integrated,  resulting  in  not  only 
safer,  but  more  cost-effective  opera- 
tions. 

During  the  1970s,  ROV  develop- 
ment was  essentially  pursued  along  a 
separate  path  from  manned  diving 
technology  and  experience.  The  re- 
sulting ROVs  were  frequently  limited 
not  only  by  the  technological  limita- 
tions of  that  time,  but  also  by  the  fact 
that  they  did  not  incorporate  the 
experience  base  gained  by  divers  who 
had  already  performed  the  tasks  that 
ROVs  were  attempting  to  accomplish. 

Today,  ROV  developments  and 
operations  are  producing  more  prac- 
tical and  sophisticated  solutions  that 
address  specific  work  task  require- 
ments defined  through  diver  expe- 
rience. To  be  sure,  free-swimming 
ROVs  are  well-suited  to  many  activ- 
ities— general  platform  visual  inspec- 
tion, pipeline  inspections,  deepwater 
drilling  support,  and  work  in  hazar- 
dous areas  where  physiological  lim- 
itations impose  their  penalties  on 
man. 

However,  existing  ROVs  reveal 
many  limitations  when  it  comes  to 
performing  complex  and  specialized 
tasks. 

Since  a very  large  percentage  of 
diver  operations  involve  the  detailed 
cleaning  and  inspection  of  node  welds 
on  offshore  structures.  Ocean  Sys- 
tems Engineering  (OSE)  wanted  to 
investigate  the  performance  possibil- 
ities of  an  ROV-based  node  weld 
cleaning  and  inspection  system.  To 


date,  this  important  task  has  been  the 
domain  of  divers  because  it  involves 
accessing  restrictive  geometries  and 
using  a variety  of  tools  that  require  a 
fairly  high  degree  of  perceptive  and 
manipulative  skills. 

From  the  analysis,  OSE  concluded 
that  although  free-swimming  ROVs 
could  be  adapted  to  perform  these 
tasks,  they  would  be  limited  by  stabil- 
ity, weld  accessibility,  inspection 
accuracy,  reproducibility,  and  over- 
complexity. OSE  also  performed  an 
economic  analysis  which  set  out  to 
project  the  cost  to  clean  and  inspect  a 
linear  square  foot  of  weld.  The  results 
indicated  that  ROV-based  systems 
would  only  be  cost-effective  when 
compared  to  diving  at  ultra-deep 
depths  or  under  special  circumstances 
where  safety,  logistics  in  remote  areas, 
labor,  and  other  factors  became  the 
overridding  consideration. 


Ideal  Machine  Task 

Nevertheless,  the  cleaning  and  in- 
spection of  node  welds  is  an  ideal 
task  to  perform  with  a machine.  The 
task  and  the  tools  required  to  per- 
form it  are  generally  well-defined. 
The  task  has  a fixed  spatial  orienta- 
tion; the  welds  have  a large  degree  of 
radial  symmetry;  it  is  repetitive;  and 
it  constitutes  a significant  portion  of 
subsea  work. 

For  these  reasons,  OSE  re-examined 
the  approach  to  this  task  using  a sys- 
tems development  methodology  that 
incorporated  existing  diver  exper- 
ience. An  outline  of  this  approach  is 
shown  in  the  chart.  Based  on  this 
approach,  OSE  developed  the  DYNA- 
CLAMP* (Dynamic  Cleaning  and 
Maintenance  Package). 

The  prototype  DYNACLAMP  is 
designed  to  be  delivered  to  the  nodal 
areas  by  a diver,  with  subsequent  ver- 


Claaning  and  inspecting  node  welds  on  offshore  structures  is  an  ideal  task  for  such 
machines  as  DYNACLAMP.  shown  hers  undergoing  tests  in  the  OSE  wet  testing  pool. 
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sions  planned  for  delivery  by  one- 
atmosphere  diving  systems  (ADS)  or 
ROVs.  The  device  attaches  to  the 
structure  using  a self-centering  hy- 
draulic clamp  and,  once  positioned, 
is  ready  to  go  to  work;  this  frees  the 
diver  (or  other  delivery  system)  to 
simultaneously  perform  other  tasks 
or  return  to  the  surface. 

DYNACLAMP  performs  its  work 
using  two  specially  designed  manipu- 
lators that  are  capable  of  accessing 
node  intersections  from  30°  to  150°. 
Operated  remotely  through  a power 
and  control  umbilical  to  the  surface, 
the  manipulators  are  designed  to 
accommodate  a variety  of  bolt-on 
cleaning  and  inspection  tools  includ- 
ing a high-pressure  water  blaster,  a 
grit  blaster,  hydraulic  wire  brushes, 
and  a number  of  photographic  sys- 
tems. This  flexibility  allows  users  to 
tailor  the  DYNACLAMP’s  cleaning 
and  inspection  methods  to  whatever 
combination  best  suits  their  require- 
ments. 

Hydraulic  power  and  control  sys- 
tems are  located  onboard,  with  elec- 
trical power,  control,  and  data  com- 
munications provided  through  an 
umbilical  link  to  the  surface.  Clean- 
ing fluids  are  also  supplied  by  an 
umbilical  from  the  surface,  leaving 
maintenance  of  the  cleaning  system 
to  surface  crews. 

Because  the  DYNACLAMP  does 
not  have  onboard  propulsion  sys- 
tems and  because  its  subsystems  are 
distributed  around  the  structural 
members,  it  has  a much  lower  height 
envelope  than  traditional  ROVs, 
which  are  larger  and  have  to  attach 
above  or  beside  the  structural  mem- 
bers. Because  of  the  lower  height 
envelope,  the  system  is  able  to  access 
restrictive  node  geometries  much  the 
way  a diver  does.  Also,  just  as  a diver 
wraps  his  legs  around  the  member 


and  rotates  around  the  weld  as  he 
works,  the  DYNACLAMP  rotates  a 
full  360°  around  the  weld,  eliminat- 
ing the  time-consuming  task  of  mul- 
tiple relocations  that  limit  the  effec- 
tiveness of  larger  ROV-based  systems. 

Symmetrical  Rotation 

The  fact  that  it  rotates  symetrically 
about  the  weld  reduces  the  demand 
on  the  topside  operator  to  continu- 
ally readjust  his  orientation  to  the 
weld — a limitation  of  ROV  opera- 
tions. Also,  the  generally  fixed  rela- 
tionship between  the  weld  and  the 
work  system  allowed  the  manipula- 
tors to  be  designed  for  performing 
these  specific  tasks,  which  greatly 
reduces  operator  demands. 

Asa  complementary  system,  DYNA- 
CLAMP can  support  and  supple- 
ment divers  in  several  ways.  Since  it 
is  not  subject  to  bottom  time  restric- 
tions, one  unit  can  work  steadily 
through  the  time  it  would  take  a 
number  of  divers  to  complete  the 
same  task.  For  surface  diving — 
whether  bouncing  to  intermediate 
depths  or  working  in  shallow  water — 
the  diver  need  only  spend  the  time  it 
takes  to  reposition  the  system  at 
another  node;  if  he  chooses  to  work 
at  shallower  depths,  or  even  return  to 
the  surface,  he  spends  less  bottom 
time  and  decompression  time.  This 
capability  should  extend  the  depth  at 
which  surface  diving  is  a practical 
option. 

In  conjunction  with  saturation  div- 
ing, the  system  can  work  simultane- 
ously with  the  divers  and  also  through 
diving  bell  launch  and  recovery  peri- 
ods. This  capability  has  the  potential 
to  significantly  increase  the  daily 
production  rates  of  an  expensive  sat- 
uration diving  spread  with  only  an 
incremental  increase  in  costs. 

Another  advantage  of  the  DYNA- 
C LAMP/diver  combination  is  that 
the  diver  will  be  available  to  perform 
the  more  sophisticated  non-destructive 
testing  (NDT)  inspections  if  required 
and  also  to  perform  the  cleaning  and 
inspection  on  nodes  where  obstruc- 
tions such  as  debris  and  sacrificial 
anodes  might  impair  DYNACLAMP’s 
performance. 

In  preliminary  onshore  wet  test- 
ing, the  system  has  matched  diver 
rates  for  cleaning  and  photographic 
documentation  with  no  decrease  in 
quality.  Based  on  the  performance 
data  from  these  initial  tests  and  using 
a computerized  cost  model,  potential 
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cost-effectiveness  projections  were 
made  for  use  of  the  DYNACLAMP 
compared  to,  and  in  conjunction 
with,  standard  diving  techniques. 
These  projections  are  shown  in  the 
accompanying  graph  for  the  Gulf  of 
Mexico.  (The  projections  for  cost 
savings  are  even  more  dramatic  for 
the  North  Sea.) 

The  system  is  scheduled  for  more 
exhaustive  onshore  testing  and  anal- 
ysis, and  then  offshore  trials  in  1987. 
Initially,  it  will  be  deployed  by  divers 
to  establish  a baseline  of  experience 
in  delivery  requirements  before  turn- 
ing the  task  over  to  ROVs  and  ADSs. 


Add  Sensors,  Machine  Vision? 

Future  refinements  to  this  type  of 
work  system  will  concentrate  on  add- 
ing advanced  sensory  and  machine 
vision  systems  along  with  advanced 
NDT  systems — all  of  which  can  be 
integrated  with  some  degree  of  artifi- 
cial intelligence  that  can  make  the 
unit  more  independent  of  diver  inter- 
vention. All  these  future  advance- 
ments will  build  on  the  baseline  expe- 
rience provided  by  divers  performing 
similar  tasks  in  conjunction  with 
DYNACLAMP. 


This  cleaning  and  maintenance  sys- 
tem is  an  excellent  example  of  how 
company  can  draw  upon  their  expe 
rience  to  direct  their  next  technologi- 
cal step.  By  charting  the  methodol- 
ogy of  a specified  task  and  analyzing 
how  divers  have  done  it  in  the  past, 
engineers  can  pinpoint  the  particular 
skills  and  requirements  of  that  task. 

The  next  step  is  to  determine 
whether  a reliable  work  system  can 
be  developed  at  a reasonable  cost  rel- 
ative to  its  potential  to  save  diver 
hours  while  maintaining  or  increas- 
ing safety  standards.  /«/ 


Mike  Gemhardt  has  accumulated  ten 
years'  experience  in  commercial  diving, 
including  six  in  the  field  as  a diver  and 
diving  supervisor.  At  Ocean  Systems 
Engineering,  he  is  involved  with  de- 
veloping advanced  work  capabilities  for 
subsea  and  space  applications— including 
remote  and  intelligent  work  systems  and 
advanced  inspection  technqiues.  Gem- 
hardt and  OSE  are  also  looking  at  new 
decompression  techniques  to  improve 
diver  safety  and  performance.  He  holds  A 
bachelor's  and  a master  of science  degree 
in  engineering  from  Vanderbilt  Univer- 
sity and  the  University  of  Pennsylvania, 
respectively. 
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REVIEW 
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Information  Flow  Model  Space  Station  Ground  Operations 
Assumptions 

1.  Support  time  period  is  the  operational  (post  manufacturing 
and  assembly)  era. 

2.  Station  operations  are  functionally  composed  of  mission 
operations,  ground  operations,  management  structures  (Levels 
A&A ' ) , Logistics,  Configuration  Management,  Sustaining 
Engineering,  Information  Systems  & Communications,  Safety, 
Reliability  and  Quality  Assurance  and  SS  Users  (experimenters  & 
Payload  Owners). 

3.  Only  informatin  flow  is  modeled.  Physical  parts  (failed 
ORU's,  logistics  modules,  payloads)  are  not  modeled  as  part  of 
this  exercise. 

4.  Data  applies  to  all  forms  of  data;  ie.:  Drawings,  thermal 

models,  processed  engineering  reports,  etc  are  part  of 
Eningeering  data. 

5.  Budgetary  marks  and  performance  are  assumed  to  flow  with 
planning  and  reporting  data. 

6.  Data  owners  by  function: 

a.  Engineering  data:  Sustaining  Engineering 

b.  Configuration  data:  Configuration  management 

c.  Strategic  planning:  Level  A thru  Level  A' 

d.  Commonality  data:  Configuration  Management 

e.  Repair  paper:  Safety,  Reliability  and  Quality 

Assurance 

7.  Only  data  that  crosses  functional  boundaries  is  modeled. 
Internal  planning,  for  example,  doen  not  appear  in  te  Model. 

8.  Only  ground  operations  data  is  modeled.  Space  Station 
uplink  and  downlink  and  mission  coordination  data  (e.i.,  SSCC  to 
Space  Station  User  POCC)  is  not  included. 


LEVEL  A 


OUTPUTS 

DESTINATION 

.1.1 

.1.2 

STRATEGIC  PLANS 
STRATEGIC  PLANS 

NASA  CENTERS 
LEVEL  A' 

.2 

LEVEL  A SUPPORT  REQ. 

IS&C 

INPUTS 

SOURCE 

NATIONAL  GOALS 

EXTERNAL 

.2 

STRATEGIC  PERFORMANCE 

LEVEL  A' 

.3.1 

SUPPORT  SERVICES 

IS&C 
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LEVEL  A1 


OUTPUTS 

DESTINATION 

2.1.1 

TACTICAL  PLANS 

G.OPS 

2.1.2 

TACTICAL  PLANS 

SR&QA 

2.1.3 

TACTICAL  PLANS 

LOGISTICS 

2.1.4 

TACTICAL  PLANS 

CM 

2.1.5 

TACTICAL  PLANS 

IC&S 

2.1.6 

TACTICAL  PLANS 

F .OPS 

2.1.7 

TACTICAL  PLANS 

S E 

2.2 

STRATEGIC  PERFORMANCE 

LEVEL  A 

2.3 

LEVEL  A SUPPORT  REQ. 

IS&C 

2.4 

PLANNING /SCHED /MANIFEST 

SS  USERS 

2.5 

RESOURCE  ALLOCATIONS 

SS  USERS 

INPUTS 

SOURCE 

6.3.2 

SUPPORT  SERVICES 

IS&C 

5.2 

SS  USER  REQ. 

SS  USERS 

8.2 

CHANGE  PAPER 

F .OPS 

7.2 

CHANGE  PAPER 

G.OPS 

4.5 

CHANGE  PAPER 

CM 

9.5 

CHANGE  PAPER 

SE 

1.1.2 

STRATEGIC  PLANS 

LEVEL  A 

3.5.5 

PERFORMANCE 

LOGI 

4.1 

PERFORMANCE 

CM 

9.1 

PERFORMANCE 

SE 

8.3.1 

PERFORMANCE 

F .OPS 

7.3.1 

PERFORMANCE 

G.OPS 

5.5.4 

PERFORMANCE 

SS  USERS 

10.1 

PERFORMANCE 

SR&QA 

6.2 

PERFORMANCE 

IS&C 

6.1.1 

IS&C  PLANS  & SCHEDULES 

IS&C 
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LOGISTICS 


OUTPUTS 


DESTINATION 


3.1  PURCHASE  ORDERS  EXTERNAL 

( VENDORS ) 

3.2  LAUNCH  REQ.  G.  OPS 

3.3 


3.4.1  PLANNING/SCHED/MANIFEST  CM 

3.4.2  PLANNING/SCHED/MANIFEST  G.OPS 


3.4.3  PLANNING/SCHED/MANIFEST 

3.4.4  PLANNING/SCHED/MANIFEST 

3.4.5  PLANNING/SCHED/MANIFEST 

3.4.6  PLANNING/SCHED/MANIFEST 

3.4.7  PLANNING/SCHED/MANIFEST 


F .OPS 
SE 

SS  USERS 
ELV 

EXTERNALS 


3.5.1  PERFORMANCE 

3.5.2  PERFORMANCE 

3.5.3  PERFORMANCE 

3.5.4  PERFORMANCE 

3.5.5  PERFORMANCE 

3.5.6  PERFORMANCE 


F. OPS 

G. OPS 
CM 

SE 

LEVEL  A1 
EXTERNAL 
( VENDORS ) 


3.6  REPAIR  PAPER  SR&QA 

3.7  LOGISTICS  SUPPORT  REQ.  IS&C 


3.8.1  MOD  KIT  DATA  F.OPS 

3.8.2  MOD  KIT  DATA  G.OPS 


3.9.1  COMMONALITY  DATA 

3.9.2  COMMONALITY  DATA 

3.9.3  COMMONALITY  DATA 


EXTERNAL 

SE 

CM 


3.10  TREND  ANALYSIS 


SS  USER 


3.11.1  MOD  STATUS 

3.11.2  MOD  STATUS 


EXTERNAL 
( VENDORS ) 
CM 


3.12.1  RESOURCE  UTILIZATION 

3.12.2  RESOURCE  UTILIZATION 


EXTERNAL 
(VENDORS) 
LEVEL  A' 


3.13  CONFIGURATION  DATA 


CM 


M-6 


LOGISTICS  (CONTINUED) 


4.3.4 

8.11 

5.15 

9.3.1 

5.9.1 

9.9 

5.10 


2.1.3 

9.2.4 


8.8.2 

5.12.1 

8.9 

5.13 
9.16 

9.13 
5.7 


6.3.3 

9.6.5 


5.4. 

9.15.1 

9.15.2 


INPUTS 


SOURCE 


MOD  REPORT 


CM 


DOWNMASS  REQ. 
DOWNMASS  REQ. 


F .OPS 
SS  USERS 


TREND  ANALYSIS  SE 

TREND  ANALYSIS 


MANIFEST  INPUTS  SE 

MANIFEST  INPUTS  STS 

MANIFEST  INPUTS  SS  USERS 

MANIFEST  INPUTS  ELV 

TACTICAL  PLANS  LEVEL  A' 

ENGINEERING  DATA  SE 


ENGINEERING  DATA 
ENGINEERING  DATA 


RESOURCE  UTILIZATION  F.OPS 

RESOURCE  UTILIZATION  SS  USERS 

RESUPPLY  REQ..  F.OPS 

RESUPPLY  REQ.  SS  USERS 

RESUPPLY  REQ.  SE 

MOD  KIT  DATA  SE 

MOD  KIT  DATA  SS  USERS 

MOD  KIT  DATA  WPl-5 

SUPPORT  SERVICES  IS&C 

PROCEDURE  INPUTS  SE 

INTERFACE  TEST  REQ.  WPl-5 

INTERFACE  TEST  REQ.  EXTERNAL 

(VENDORS) 

LOGISTICS  REQ.  SS  USERS 

BILL  OF  MATERIALS  SE 

BILL  OF  MATERIALS  WPl-5 


M-7 


4.2.4 
4.6.1 

10.6.4 


8.10 


LOGISTICS  (CONTINUED) 

INPUTS 

CONFIGURATION  REPORT 
COMMONALITY  REPORT 
REPAIR  CLOSEOUT 
TECHNICAL  DATA 
TECHNICAL  DATA 

CONSUMABLE  UTILIZATION 


CM 

CM 

SR&QA 

EXTERNAL 
(VENDORS  & WP) 
SPACE  STATION 
USERS 

F .OPS 
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CONFIGURATION  MANAGEMENT 


OUTPUT 

DESTINATION 

4.1 

PERFORMANCE 

LEVEL  A' 

4.2.1 

CONFIGURATION 

REPORT 

F .OPS 

4.2.2 

CONFIGURATION 

REPORT 

G.OPS 

4.2.3 

SR&QA 

4.2.4 

CONFIGURATION 

REPORT 

LOG  I 

4.2.5 

CONFIGURATION 

REPORT 

SR&QA 

4.2.6 

CONFIGURATION 

REPORT 

SE 

4.2.7 

CONFIGURATION 

REPORT 

SS  USERS 

4.3.1 

MOD 

REPORT 

F .OPS 

4.3.2 

MOD 

REPORT 

G.OPS 

4.3.3 

MOD 

REPORT 

SR&QA 

4.3.4 

MOD 

REPORT 

LOG  I 

4.3.5 

SS  USER 

4.3.6 

MOD 

REPORT 

SE 

4.3.7 

MOD 

REPORT 

SS  USERS 

4.4 

CM  SUPPORT  REQ. 

IS&C 

4.5 

CHANGE  PAPER 

LEVEL  A ' 

4.6.1 

COMMONALITY  REPORT 

LOG  I 

4.6.2 

COMMONALITY  REPORT 

SR&QA 

4.6.3 

COMMONALITY  REPORT 

SS  USER 

4.6.4 

COMMONALITY  REPORT 

SE 

4.7 

REPAIR  PAPER 

SR&QA 

M-9 


CONFIGURATION  MANAGEMENT  (CONTINUED) 


INPUTS 

SOURCE 

• 

r-j 

• 

CN 

TACTICAL  PLANS 

LEVEL  A' 

3.4.1 

PLANNING/ SCHED/MANIFEST 

LOGI 

10.3.5 

SAFETY  REPORT 

SR&QA 

CONFIG.  DATA 

WP1-4 

5.6.1 

CONFIG.  DATA 

SS  USER 

8.6 

CONFIG.  DATA 

F .OPS 

7.8 

CONFIG.  DATA 

G.OPS 

3.13 

CONFIG.  DATA 

LOGI 

8.7 

MOD  STATUS 

F.OPS 

7.9 

MOD  STATUS 

G.OPS 

10.5 

MOD  STATUS 

SR&QA 

3.11.2 

MOD  STATUS 

LOGI 

3.9.3 

COMMONALITY  DATA 

LOGI 

COMMONALITY  DATA 

EXTERNAL 

5.14 

COMMONALITY  DATA 

SS  USER 

9.7 

COMMONALITY  DATA 

SE 

10.6.5 

REPAIR  CLOSEOUT 

SR&QA 

3.5.3 

PERFORMANCE 

LOGI 

6.3.4 

SUPPORT  SERVICES 

IS&C 
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SS  USERS 


OUTPUTS 

DESTINATION 

5.1 

SS  USERS  SUPPORT  REQ. 

IS&C 

5.2 

SS  USERS  REQ. 

LEVEL  A' 

5.3.1 

TEST  REQ. 

SE 

5.3.2 

TEST  REQ. 

F .OPS 

5.3.3 

TEST  REQ. 

G.OPS 

5.4 

LOGISTICS  REQ. 

LOGI 

5.5.1 

PERFORMANCE 

SE 

5.5.2 

PERFORMANCE 

G.OPS 

5.5.3 

PERFORMANCE 

F.OPS 

5.5.4 

PERFORMANCE 

LEVEL  A' 

5.5.5 

PERFORMANCE 

EXTERNAL 

5.5.6 

5.6.1 

CONFIGURATION  DATA 

CM 

5.6.2 

5.7 

MOD  KIT  DATA 

LOGI 

5.8 

PRE/POST  FLIGHT  REQ. 

G.OPS  - 

5.9.1 

TREND  ANALYSIS 

LOGI 

5.9.2 

TREND  ANALYSIS 

SE 

5.10 

MANIFEST  INPUTS 

LOGI 

5.11 

ENGINEERING  DATA 

SE 

5.12.1 

RESOURCE  UTILIZATION 

LOGI 

5.12.2 

RESOURCE  UTILIZATION 

SE 

5.13 

RESUPPLY  REQ. 

LOGI 

5.14 

COMMONALITY  DATA 

CM 

5.15 

DOWNMASS  REQ. 

LOGI 

5.16 

REPAIR  PAPER 

SR&QA 
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SS  USERS  (CONT) 


INPUTS 

SOURCE 

9.2.5 

ENGINEERING  DATA 

SE 

3.4.5 

2.4 

PLANNING/SCHED/MANIFEST 

PLANNING/SCHED/MANIFEST 

LOGI 
LEVEL  , 

2.5 

RESOURCE  ALLOCATIONS 

LEVEL 

9.10.3 

INTERFACE  TEST  REQ. 

SE 

4.2.7 

CONFIGURATION  REPORT 

CM 

6.3.8 

SUPPORT  SERVICES 

IS&C 

3.10 

TREND  ANALYSIS 

LOGI 

4.3.7 

MOD  REPORT 

CM 

4.6.3 

COMMONALITY  REPORT 

CM 

9.12.3 

RESOURCE  UTIL.  REPORT 

SE 

10.6.8 

REPAIR  CLOSEOUT 

SR&QA 
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INFORMATION  SYSTEMS  & COMMUNICATIONS 


OUTPUTS 

DESTINATION 

6.1.1 

IS&C  PLANS  & SCHEDULES 

LEVEL  A' 

6.1.2 

IS&C  PLANS  & SCHEDULES 

F .OPS 

6.1.3 

IS&C  PLANS  & SCHEDULES 

G.OPS 

6.2 

PERFORMANCE 

LEVEL  A' 

6.3.1 

SUPPORT 

SERVICES 

LEVEL  A 

6.3.2 

SUPPORT 

SERVICES 

LEVEL  A' 

6.3.3 

SUPPORT 

SERVICES 

LOGI 

6.3.4 

SUPPORT 

SERVICES 

CM 

6.3.5 

SUPPORT 

SERVICES 

F .OPS 

6.3.6 

SUPPORT 

SERVICES 

SE 

6.3.7 

SUPPORT 

SERVICES 

SR&QA 

6.3.8 

SUPPORT 

SERVICES 

SS  USERS 

6.3.9 

SUPPORT 

SERVICES 

G.OPS 

INPUTS 

SOURCE 

8.4 

F .OPS  SUPPORT  REQ. 

F .OPS 

9.11 

SE  SUPPORT  REQ. 

SE 

3.7 

LOGISTICS  SUPPORT  REQ. 

LOGI 

4.4 

CM  SUPPORT  REQ. 

CM 

1.2 

LEVEL  A 

SUPPORT  REQ. 

LEVEL  A 

2.3 

LEVEL  A' 

SUPPORT  REQ. 

LEVEL  A' 

7.6 

G.OPS  SUPPORT  REQ. 

G.OPS 

10.2 

SR&QA  SUPPORT  REQ. 

SR&QA 

2.1.5 

TACTICAL 

PLANS 

LEVEL  A' 

5.1 

SS  USERS 

SUPPORT  REQ. 

SS  USERS 

M-13 


GROUND  OPERATIONS 


OUTPUTS 

DESTINATION 

7.1.1 

TACTICAL  PLANS 

STS 

7.1.2 

TACTICAL  PLANS 

ELV 

• 

K> 

CHANGE  PAPER 

LEVEL  A* 

7.3.1 

PERFORMANCE 

LEVEL  A' 

7.3.2 

PERFORMANCE 

F.OPS 

7.3.3 

PERFORMANCE 

SE 

7.4 

7.5.1 

FACILITY  UTILIZATION 

SE 

7.5.2 

FACILITY  UTILIZATION 

SR&QA 

7.6 

G.OPS  SUPPORT  REQ. 

IS&C 

7.7 

00 

• 

CONFIGURATION  DATA 

CM 

7.9 

MOD  STATUS 

CM 

7.10 

REPAIR  PAPER 

SR&QA 

M-14 


GROUND  OPERATIONS  ( CONT ) 


INPUTS 

2.1  TACTICAL  PLANS 

3.2.  LAUNCH  REQ. 

3.4.2  PLANNING/ SCHED /MANIFEST 

8.14.1  PLANNING/SCHED/MANIFEST 

5.3.3  TEST  REQ. 

9.10.2  TEST  REQ. 

8.12.1  TEST  REQ. 

10.7.2  TEST  REQ. 

6.3.9  SUPPORT  SERVICES 

PERFORMANCE 

PERFORMANCE 

8.3.3  PERFORMANCE 

5.5.2  PERFORMANCE 

4.3.2  MOD  REPORT 

3.8.2  MOD  KIT  DATA 

9.2.2  ENGINEERING  DATA 

9.6.2  PROCEDURE  INPUTS 
8.13.1  PROCEDURE  INPUTS 

3.5.2  PERFORMANCE 

5.8  PRE/POST  FLIGHT  REQ. 

6.1.3  IS&C  PLANS  & SCHEDULES 
4.2.2  CONFIGURATION  REPORT 

10.6.3  REPAIR  CLOSEOUT 

10.4.3  SAFETY  STANDARDS 

10.3.3  SAFETY  REPORT 


SOURCE 

LEVEL  A' 

LOGI 

LOG  I 
F .OPS 

SS  USERS 
SE 

F .OPS 
SR&QA 

IS&C 

STS 
ELV 
F .OPS 
SS  USERS 

CM 

LOGI 

SE 

SE 

F .OPS 
LOGI 

SS  USERS 

IS&C 

CM 

SR&QA 

SR&QA 

SR&QA 


M-15 


FLIGHT  OPERATIONS 


OUTPUTS 

DESTINATION 

8.1.1 

TACTICAL  PLANS 

STS 

8.1.2 

TACTICAL  PLANS 

ELV 

8.2 

CHANGE  PAPER 

LEVEL  A' 

8.3.1 

PERFORMANCE 

LEVEL  A’ 

8.3.2 

PERFORMANCE 

SE 

8.3.3 

PERFORMANCE 

G.OPS 

8.4 

F.OPS  SUPPORT  REQ. 

IS&C 

8.5. 

REPAIR  PAPER 

SR&QA 

8.6 

CONFIGURATION  DATA 

CM 

8.7 

MOD  STATUS 

CM 

8.8.1 

RESOURCE  UTILIZATION 

SE 

8.8.2 

RESOURCE  UTILIZATION 

LOGI 

8.9 

RESUPPLY  REQ . 

LOG  I 

8.10 

CONSUMABLE  UTILIZATION 

LOGI 

8.11 

DOWNMASS  REQ. 

LOGI 

8.12.1 

TEST  REQUIREMENTS 

G.OPS 

8.12.2 

TEST  REQUIREMENTS 

SE 

8.13.1 

PROCEDURE / INPUTS 

G.OPS 

8.13.2 

PROCEDURE /INPUTS 

SE 

8.14.1 

PLANNING/SCHED/MANIFEST 

G.OPS 

M-16 


r i 

L A 


PLIGHT  OPS  (CONT) 


INPUTS 

SOURCE 

1.6 

TACTICAL  PLANS 

LEVEL  A* 

8.1 

MOD  KIT  DATA 

LOG  I 

4.3 

PLANNING/SCHED/MANIFEST 

LOG  I 

• 

PLANNING/SCHED/MANIFEST 

LEVEL  A' 

• 

PLANNING/SCHED/MANIFEST 

SE 

12.2 

RESOURCE  UTIL.  REPORT 

SE 

2.1 

ENGINEERING  DATA 

SE 

6.1 

PROCEDURE  INPUTS 

SE 

5.3 

PERFORMANCE 

SS  USERS 

5.1 

PERFORMANCE 

LOG  I 

3.2 

PERFORMANCE 

G .OPS 

2.1 

CONFIGURATION  REPORT 

CM 

1.2 

IS&C  PLANS  & SCHEDULES 

IS&C 

3.5 

SUPPORT  SERVICES 

IS&C 

3.1 

MOD  REPORT 

CM 

.6.3 

REPAIR  CLOSEOUT 

SR&QA 

3.2 

TEST  REQUIREMENTS 

SS  USERS 
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SUSTAINING  ENGINEERING 


OUTPUTS 

DESTINATION 

9.1 

PERFORMANCE 

LEVEL  A' 

9.2.1 

ENGINEERING  DATA 

F .OPS 

9.2.2 

ENGINEERING  DATA 

G .OPS 

9.2.3 

ENGINEERING  DATA 

SR&QA 

9.2.4 

ENGINEERING  DATA 

LOG  I 

9.2.5 

ENGINEERING  DATA 

SS  USERS 

9.2.6 

ENGINEERING  DATA 

CM 

9.3.1 

TREND  ANALYSIS 

LOG  I 

9.3.2 

TREND  ANALYSIS 

SR&QA 

9.4.1 

MISSION  INPUTS 

STS 

9.4.2 

MISSION  INPUTS 

ELV 

9.5 

CHANGE  PAPER 

LEVEL  A' 

9.6.1 

PROCEDURE  INPUTS 

F .OPS 

9.6.2 

PROCEDURE  INPUTS 

G.OPS 

9.6.3 

PROCEDURE  INPUTS 

STS 

9.6.4 

PROCEDURE  INPUTS 

ELV 

9.6.5 

PROCEDURE  INPUTS 

LOG  I 

9.7 

COMMONALITY  DATA 

CM 

9.8 

PARTS,  INSTRUCTIONS 

LOG  I 

9.9 

MANIFEST  INPUTS 

LOGI 

9.10.1 

TEST  REQUIREMENTS 

F .OPS 

9.10.2 

TEST  REQUIREMENTS 

G.OPS 

9.10.3 

TEST  REQUIREMENTS 

SS  USERS 

9.11 

SE  SUPPORT  REQ. 

IS&C 

9.12.1 

RESOURCE  UTILIZATION  REPORT 

LOGI 

9.12.2 

RESOURCE  UTILIZATION  REPORT 

F .OPS 

9.12.3 

RESOURCE  UTILIZATION  REPORT 

SS  USERS 

9.13 

MOD  KIT  DATA 

LOGI 

9.14 

REPAIR  PAPER 

SR&QA 

9.15.1 

BILL  OF  MATERIALS 

LOGI 

9.16 

RESUPPLY  REQ. 

LOGI 
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SUSTAINING  ENGINEERING  (CONT) 


INPUTS 

SOURCE 

2.1.7 

TACTICAL  PLANS 

LEVEL  A' 

8.8.1 

RESOURCE  UTILIZATION 

F.OPS 

8.3.2 

PERFORMANCE 

F .OPS 

7.3.3 

PERFORMANCE 

G.OPS 

5.5.1 

PERFORMANCE 

SS  USERS 

3.4.4 

PLANNING/ SCHED /MANIFEST 

LOG  I 

10.3.1 

SAFETY  REPORTS 

SR&QA 

4.2.6 

CONFIGURATION  REPORT 

CM 

4.3.6 

MOD  REPORTS 

CM 

3.9.2 

COMMONALITY  DATA 

LOG  I 

• • 

COMMONALITY  DATA 

EXTERNAL 

• • 

COMMONALITY  DATA 

SS  USERS 

10.6.6 

REPAIR  CLOSEOUT 

SR&QA 

3.5.4 

PERFORMANCE 

LOGI 

5.3.1 

TEST  REQ. 

SS  USERS 

5.9.2 

TREND  ANALYSIS 

SS  USERS 

5.11 

ENGINEERING  DATA 

SS  USERS 

5.12.2 

RESOURCE  UTILIZATION 

SS  USERS 

6.3.6 

SUPPORT  SERVICES 

IS&C 

4.6.4 

COMMONALITY  REPORT 

CM 

7.5.1 

FACILITY  UTILIZATION 

G.OPS 

10.4.1 

SAFETY  STANDARDS 

SR&QA 
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SAFETY,  RELIABILITY  & QUALITY  ASSURANCE 


OUTPUTS 

DESTINATION 

10.1 

PERFORMANCE 

LEVEL  A' 

10.2 

SR&QA  SUPPORT  REG. 

IS&C 

10.3.1 

SAFETY 

REPORT 

SE 

10.3.2 

SAFETY 

REPORT 

F.  OPS 

10.3.3 

SAFETY 

REPORT 

G.  OPS 

10.3.4 

SAFETY 

REPORT 

LEVEL  A' 

10.3.5 

SAFETY 

REPORT 

CM 

10.3.6 

SAFETY 

REPORT 

IS&C 

10.3.7 

SAFETY 

REPORT 

SPACE  STATION 
USERS 

10.3.8 

SAFETY 

REPORT 

LOGI 

10.4.1 

SAFETY 

STANDARDS 

SE 

10.4.2 

SAFETY 

STANDARDS 

F.  OPS 

10.4.3 

SAFETY 

STANDARDS 

G.  OPS 

10.4.4 

SAFETY 

STANDARDS 

LEVEL  A' 

10.4.5 

SAFETY 

STANDARDS 

CM 

10.4.6 

SAFETY 

STANDARDS 

IS&C 

10.4.7 

SAFETY 

STANDARDS 

SPACE  STATION 
USERS 

10.4.8 

SAFETY 

STANDARDS 

LOGI 

10.5 

MOD  STATUS 

CM 

10.6.1 

REPAIR 

CLOSEOUT 

LEVEL  A' 

10.6.2 

REPAIR 

CLOSEOUT 

F.  OPS 

10.6.3 

REPAIR 

CLOSEOUT 

G.  OPS 

10.6.4 

REPAIR 

CLOSEOUT 

LOGI 

10.6.5 

REPAIR 

CLOSEOUT 

CM 

10.6.6 

REPAIR 

CLOSEOUT 

SE 

10.6.7 

REPAIR 

CLOSEOUT 

IS&C 

10.6.8 

REPAIR 

CLOSEOUT 

SS  USERS 

10.6.9 

REPAIR 

CLOSEOUT 

EXTERNAL 
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INPUTS 

2.1.2  TACTICAL  PLANS 

9.2.3  ENGINEERING  STAT 

4.2.5  CONFIGURATION  REPORT 

4.3.3  MOD  REPORT 

4 . 7 REPAIR  PAPER 

9.14  REPAIR  PAPER 

3 . 6 REPAIR  PAPER 

8 . 5 REPAIR  PAPER 

7.10  REPAIR  PAPER 

5.16  REPAIR  PAPER 

REPAIR  PAPER 

4.6.2  COMMONALITY  REPORT 

6.3.7  SUPPORT  SERVICES 

7.5.2  FACILITY  UTILIZATION 


DESTINATION 
LEVEL  A' 

SE 

CM 

CM 

CM 

SE 

LOGI 

F.  OPS 

G.  OPS 
SS  USERS 
EXTERNAL 
CM 

IS&C 

G.OPS 
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APPENDIX  N 


SPACE  STATION  FACILITIES 
White  Paper 


Objective:  This  paper  represents  the  recommended  Facility 

Maintenance  Concept,  and  identifies  the  Required 
Operations  Facilities  for: 

Space  Operations 
Ground  Operations 
Customer  Integration 

This  paper  also  presents  the  Operations  Task  Force's  recommendations 
for  disposition  of  proposed  Space  Station  Facilities. 

1.0  Facility  Maintenance  Concept 

The  Base  Operations  Contractor  will  be  responsible  for  utili- 
ties and  basic  building  maintenance.  The  OPS  Contractor  ( PGOC 
at  KSC)  will  be  responsible  for  maintenance  of  GSE,  FSE,  flight 
hardware  and  systems,  and  equipment  that  interfaces  with  flight 
hardware . 

Specific  responsibilities  are: 


Potable  water  BOC 

Sewage  Systems  BOC 

Painting  BOC 

Janitorial  BOC 

Roof  repair  BOC 

Relocating  doors/floor  to  ceiling  walls  BOC 

Administrative  Telephones,  FTS  BOC 

Power  distribution  to  ckt  breaker  BOC 

Heating  ventilation  & air  conditioning  BOC 

Phenmatic  system  (GN~,  Shopair)  up  to 

Reg . Panel  BOC 

Maintenance  of  cranes,  elevators,  and  doors  BOC 

Processing  operations  PGOC 

GSE  O&M  PGOC 

FSE  maintenance  PGOC 

Flight  hardware  PGOC 

Housekeeping  in  OPS  areas  PGOC 

Operation  of  doors  & cranes  PGOC 

Processing  Ops  in  Oser  Areas  USER 

Maintenance  of  User  GSE  & Equipment  USER 


N-l 


2 . 0 Space  Operations  Facilities 


MS  IF 

Multi-systems  integration  FAC 

SSSC 

Space  Station  Support  Center 

SSTF 

Space  Station  Training  FAC 

POCC 

Payload  OPS  Control  Center 

S/W  Prod  FAC 

Software  Production  Facility 

SSSI&L 

Space  Station  Sys  Integration  & Lab  Mock-up 

POIC 

Payload  Operations  Integration  Center 

ROF 

Regional  Ops  FAC 

DOC 

Discipline  Ops  Center 

DOF 

User  Ops  Facility 

ESC 

Engineering  Support  Centers 

SSIS 

Space  Station  Information  System 

SSIS  consists 

of : 

- TDRS 

Satellites 
Ground  Stations 

DIF  Data  Interface  Fac 


- PSCN 
And 

- NASCOM 
connection  among 

SSSC  Space  Station  Support  Center 

SSTF  Space  Station  Training  Facility 

CCC  Customer  Coordination  Capability 

SSOMF  Space  Station  Ops  Mgmt.  Function 

MACC  Multiple  Application  Control  Center 

DHC  Data  Handling  Center 

CDSF  Customer  Data  Services  FAC 

ESC  Engineering  Support  Center 

POIC  Payload  Ops  Integration  Center 
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PSC  Platform  Support  Center 

IGE  International  Ground  Elements 

IPF  International  Partner  FAC 

ICN  International  Comm.  Network 

ITVF  Integration  Test  & Verification  FAC 

SPF  Software  Production  FAC 

EAF  Engineering  Analysis  FAC 


3 . 0 Ground  Operations  Facilities 

3.1  Information  and  Communication  Systems 
Central  Computing  Facility 

This  Facility  will  house  the  computer  hardware  and  related 
systems  and  equipment  to  support  the  Space  Station  Developed 
Data  Bases.  The  major  data  bases  to  be  developed  are  the 
Logistics  Information  System,  the  Sustaining  Engineering  Data 
Base,  and  the  Configuration  Management  System. 

3 . 2 Prelaunch  - Post  landing  Processing  Facilities 
Space  Station  Processing  Facility  (SSPF) 

The  SSPF  is  a new  facility  to  be  built  at  KSC  to  perform  the 
prelaunch  processing  of  Space  Station  Elements,  systems, 
equipment  and  payloads.  The  integration  and  interface  verifi- 
cation of  "Launch  Packages”  will  be  done  in  this  facility.  The 
estimated  $69. 5M  CofF  and  $101M  R&D  cost  is  approved,  and 
budgeted. 

Baseline  Data  Collection  Facility 

A Crew  Baseline  Data  Collection  Facility  (BDCF)  is  required  at 
each  launch  and  landing  site.  Existing  BDCF's  at  KSC  and  DFRF 
currently  supporting  the  NSTS  will  be  required  to  support 
determination  of  potential  of  the  long-term  humans  in  Space 
Program.  This  will  require  the  maintenance  of  the  BDCF's  to  he 
year  2010  and  beyond. 

Materials  Processing  and  Life  Sciences  User  Facility 

This  facility  must  support  the  following  requirements: 

o Assure  animal  specimens  conform  to  defined 
microbiological  requirements  preflight. 

o Assure  that  animals  are  cared  for  and  maintained  per 
AALAC  procedures.  (Both  O.S.  & International) 
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o Provide  sterilization  (autoclave,  ethylene  oxide,  and 
irradiation)  capability,  system  evacuation  and 
pressurization,  and/or  incubation. 

o Immediate  post-flight  analysis  and  testing  of  live 
specimens . 

Space  Station  Hazardous  Processing  Facility  (SSHPF) 

The  SSHPF  was  to  be  a new  facility  to  be  constructed  at  KSC  to 
perform  the  hazardous  loading  of  propellants  and  pressurants  in 
Space  Station  OMVS,  propellant  carriers  and  payloads.  This 
facility  has  been  dropped  from  the  program,  due  to  deletion  of 
the  Space  Station  OMV  and  the  change  to  LH2  as  the  only  fuel 
for  Station  Reboost. 

VLS  Payload  Processing  FAC  (VSLPPF) 

The  VLSPPF  is  a new  FAC  to  process  Space  Station  Polar  Orbiting 
Platforms.  Estimated  cost  is  $3M  CofF  and  $8.7M  R&D. 

MODS  to  PAD  A and  B 

Mods  to  LC  39  Launch  pads  are  planned  to  provide  required  late 
access  to  logistics  modules  and  carriers.  Estimated  cost  is 
$8.5  R&D. 

Transportation 

3 . 3 Crew  Emergency  Rescue  Vehicle  Facility 

Maintain  CERV  on  the  ground,  perform  postlanding  refurbishment, 
store  and  maintain  GSE  and  rescue  KIT.  The  rescue  KIT  is  the 
set  of  equipment  required  to  retrieve  the  CERV  and  crew  after 
a water  landing  off  the  Florida  coast.  The  facility  will 
provide  access  to  a terminal  into  the  SSIS  for  periodic  health 
checks  of  on  orbit  CERV's.  Synergism  can  be  achieved  by 
combination  with  the  OMV  facility  planned  by  the  STS  program. 

3 . 4 Logistics 

Initial  Logistics  support  will  be  provided  by: 


Mods 

Year 

Cost 

Budgeted 

Warehouse  #1 

M6-794 

$616K 

FY90 

Ship  & Rec 

M7-505 

$199K 

FY90 
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Space  Station  Logistics  FAC  (SSLF) 


The  Space  Station  Logistics  Facility  will  provide  the  capabili 
ty  to  consolidate  and  integrate  Space  Station  Logistics  Activi 
ty  including: 

1.  Maintenance  Capability  Intermediate  & Depot 

Clean  rooms,  ATE  & software,  tech  doc,  piece  parts 
verification  and  recert.  equ. , staging  areas. 

2 . Warehouse 

Spares,  supply  support 

3 . Storage 

- GSE,  FSE,  Fit.  HW 
Customer  hardware 

4.  Logistics  Carrier/Rack  Buildup 

5.  International  Support 

6 . Shipping  and  receiving 

Packing  and  unpacking 

7.  Training  facilities 

Classrooms 

Computer  Assisted  Instructional  Trainers 
(using  AI  & Interactive  videodisk,  etc.) 

8.  Office  space  for  log.  personnel 

Gov.  and  contractor 

9.  Read/write  IF  with  data  and  info  systems 
See  Info  & Comm  Sys  Central  Computing  Fac. 

4 . 0 Customer  Integration 

CDOF  Customer  Data  & Operations  Fac 
Platform  Support  Center 
PL  accom.  Control  Center 
Servicing  Supp  Center 
Cust.  Coord.  Center  Node 
S/W  Production  FAC 
Eng.  Analysis  Capability 
Data  Handling  Center 
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SSDIF  Space  Station  Dev.  and  Integration  FAC 
Servicing  and  Assembly  Verification 
Telerobotic  Ser.  Dev.,  Test  and  Verification 
Att.  PL  Interface  Test  and  Verification 
Int.  Log  Sys.  Node 

5 . 0 Disposition  of  Proposed  Space  Station  Facilities 

The  Facilities  in  the  attached  listing  have  been  proposed  as 
Space  Station  Program  Facilities.  Many  of  these  Facilities  are 
existing  and  only  require  minor  modification  or  refurbishment 
to  support  the  Space  Station  Program.  These  Facilities  are 
proposed  for  use  by  Development  Centers,  Work  Package 
Contractors,  Payload  Users,  or  Operations  Centers /Contractors . 
All  of  these  Facilities  could  be  of  some  use  to  the  Space 
Station  Program  during  some  Phase  of  Development/Operations . 
However,  the  Space  Station  Program  is  faced  with  a strict 
limitation  on  yearly  operating  costs.  If  the  Program  accepted 
responsibility  for  Operations  and  Maintenance  of  these 
Facilities,  the  increase  in  yearly  operating  cost  would  be 
unacceptable . 

The  SSOTF  reviewed  the  Proposed  Facilities  and  Dispositioned 
each  one  into  one  of  the  following  categories: 

1 . Mandatory  for  Concept 

SSOTF  concept  cannot  work  without  this  Facility 
- The  Space  Station  Program  should  support 
development  of  these  Facilities 

2.  Need  Further  Justification/Data 

3.  Required  on  as  Needed  Basis 

Facilities  which  may  be  required  in  a specific 
Phase  of  Design,  Development,  or  Verification 
The  Space  Station  Program  should  negotiate  cost 
effective  use  of  these  Facilities 

4 . Not  Required 

The  SSOTF  concept  does  not  require  the  use  of 
these  Facilities 

The  Space  Station  Program  should  not  expend  any 
funds  for  these  Facilities 
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FACILITY  CAPABILITY  ALL  PROGRAM  PHASES 

WORKING  PAPER 
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FACILITY  CAPABILITY  ALL  PROGRAM  PHASES 
WORKING  PAPER  (CONTINUED) 
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